Solution Design Document

ABC Ltd. Group Limited

Database Re-host Design
Aug 22, 2019
Version 1.9

Ingram Micro Cloud

Corporate headquarter
3351 Michelson Dr #100,
Irvine, CA 92612, USA
 P age |1

Table of Contents
DOCUMENT HISTORY ...................................................................................................................................................... 3
DOCUMENT REVIEW ....................................................................................................................................................... 3
1. INTRODUCTION...................................................................................................................................................... 4
1.1 PREFACE ........................................................................................................................................................... 4
1.2 AUDIENCE .......................................................................................................................................................... 4
1.3 CUSTOMER REQUIREMENT ................................................................................................................................. 5
1.4 REVIEW AND VERIFICATION OF CUSTOMER REQUIREMENTS AND ASSOCIATED CHANGES ..................................... 6
1.5 SCOPE AND BUSINESS BENEFITS ........................................................................................................................ 6
1.6 DEPLOYMENT WINDOW PLANNING ..................................................................................................................... 7
1.7 COST ANALYSIS .................................................................................................................................................. 7
1.8 AZURE NAMING CONVENTIONS .......................................................................................................................... 7
1.9 RELATED DOCUMENTS ....................................................................................................................................... 7
1.10 ROLES AND RESPONSIBILITIES ........................................................................................................................... 8
2. CURRENT ARCHITECTURE ................................................................................................................................. 8
2.1 DATABASE ARCHITECTURE ................................................................................................................................ 8
2.1.1 Application Servers ................................................................................................................................. 9
2.1.2 Database Servers.................................................................................................................................... 9
3 OPERATIONAL PROCESS ..................................................................................................................................10
3.1 SERVICE MANAGEMENT ....................................................................................................................................10
3.2 SLA STRATEGY ................................................................................................................................................10
3.3 BUSINESS CONTINUITY PLANNING .....................................................................................................................10
3.4 PERFORMANCE AND OPERATIONAL HEALTH ......................................................................................................10
4 ASSESSMENT .......................................................................................................................................................10
4.1 ASSESSMENT TOOLS ........................................................................................................................................10
5 PROPOSED ARCHITECTURE .............................................................................................................................10
5.1 SOLUTION COMPONENTS ..................................................................................................................................12
5.2 HIGH AVAILABILITY (HA) ARCHITECTURE ...........................................................................................................13
5.3 FAILOVER SCENARIOS .......................................................................................................................................13
5.4 DISASTER RECOVERY ARCHITECTURE ...............................................................................................................13
5 ARCHITECTURAL REVIEW .................................................................................................................................14
6 MIGRATION STRATEGY ......................................................................................................................................14
7 CONFIGURATION PARAMETERS ......................................................................................................................14
7.1 NETWORK CONFIGURATION ..............................................................................................................................15
8 RISK IDENTIFICATION AND MITIGATION.........................................................................................................15
9 OPTIMIZING WORKLOADS .................................................................................................................................15
9.1 AZURE COST MANAGEMENT..............................................................................................................................16
9.2 TOTAL COST OF OWNERSHIP (TCO) ..................................................................................................................16
10 SECURE AND MANAGED ....................................................................................................................................16
10.1 SECURE MIGRATED WORKLOADS .....................................................................................................................16
10.2 MANAGE MIGRATED WORKLOADS .....................................................................................................................17
11 SERVICE MANAGEMENT WORKFLOWS .............................................................................................................17
11.1 PROBLEM/INCIDENT MANAGEMENT ...................................................................................................................17
11.2 CHANGE MANAGEMENT.....................................................................................................................................18
11.3 AVAILABILITY MEASUREMENT ............................................................................................................................19
 P age |2

APPENDIX A: COMMENTS AND RESPONSE ...........................................................................................................19

APPENDIX B – PEER REVIEW PROCESS.................................................................................................................19

List of Figures and Tables

Figure 1 Existing on-premises architecture .............................................................................................................. 9
Figure 3 Failover architecture .....................................................................................................................................13
Figure 4 Proposed disaster recovery architecture..................................................................................................14

Table 1 Document history............................................................................................................................................ 3

Table 3 Customer Requirement ................................................................................................................................... 6
Table 2 scheduling worksheet .................................................................................................................................... 7
Table 3 Related Documents ........................................................................................................................................ 8
Table 4 Roles and Responsibilities............................................................................................................................ 8
3. Table 5 Existing on-prem application servers’ inventory.............................................................................. 9
Table 6 Existing on-prem database servers’ inventory.........................................................................................10
Table 7 Workload assessment tools.........................................................................................................................10
Table 8 Propose Azure Solution Components........................................................................................................13
Table 10 Refactor, Rehost and Rearchitect .............................................................................................................14
Table 11 – Network Configurations...........................................................................................................................15
Table 12 Cost Analysis................................................................................................................................................16
Table 13 Azure tools. ...................................................................................................................................................17
Table 18 Policy – migrated workload management ...............................................................................................17
Table 19 Refactor, rehost and rearchitect ...............................................................................................................18
Table 20 Change management ..................................................................................................................................18
Table 21 Availability measurement ...........................................................................................................................19
Table 22 Feedback – comment and response ........................................................................................................19
 P age |3

About This Design Process

Author Debabrata Howlee

Change Authority Ingram Micro Cloud

Internal Reference <Doc ID>

Project Name Database Migration for ABC Ltd.

Document History
Version Date Status Reason for Change
0.1 26/07/2019 Draft Initial Draft
0.2 30/07/2019 Draft Updated proposed architecture
0.3 31/07/2019 Draft Updated capacity planning
0.4 02/08/2019 Draft Updated migration strategy
0.5 05/08/2019 Release Internal release
1.0 08/08/2019 First External Release Released for Customer review
1.1 12/08/2019 Update Release Updated customer requirements
1.2 14/08/2019 Update Release Modified to deployed standard.
1.5 16/08/2019 Released Tidied up the sections, indexing and overall
alignment
1.9 22/08/2019 Released Removing major sections to align with CAF
document
Table 1 Document history

Document Review
After creating an initial draft by Ingram Micro Cloud Architect, the design document will be peer reviewed
internally. The process is described in the Solution Design Document in Appendix B. Internal peer
reviewed document will have version less than 1 and customer released version will be greater than 1.

• As a standard offering the document will be once internally peer reviewed and once external/
customer peer reviewed.
• After peer review all comments/feedback will be captured in appendix A and then updated to
the document as a final design.

Version Review Date Description Role Reviewer

0.5 06/08/2019 Reviewed initial draft released Cloud Architect

by cloud architect
1.0 13/08/2019 Peer reviewed 1 Sr. Cloud Architect
1.5 21/08/2019 Peer reviewed 2 – Fit to Manager
Release
 P age |4

1. Introduction
1.1 Preface

ABC Ltd. Co-operative Group Limited is a New Zealand multinational dairy co-operative
owned by around 10,500 New Zealand farmers. It is backed by a strong IT infrastructure hosted
in traditional data centre which supports the daily operations and millions of transactions that
involves a huge amount of data. They currently have a large footprint of Microsoft SQL database.
They are in the midst of a digital transformation initiative that cuts across business units and are
looking to Azure PaaS solution to get them the needed speed and agility.

The primary purpose of this detail design is to define the Azure solution design to support
new Azure cloud-based “Infrastructure data platform” / application instances, as replacement
of existing on-premise application services. The baseline reference of this detailed design is the
customer requirement and around the best practice design recommendations from Microsoft
Azure.

This project will create the service described within this document. Putting all
infrastructure items in place, installing the application, and testing to ensure everything is
operating as expected.

This document covers the following 4 high level phases for the Azure migration process:
• Phase 1: Assessing database workloads
• Phase 2: Designing & Migrating database workloads
• Phase 3: Optimizing SQL workloads
• Phase 4: Securing and Managing SQL workloads

Ingram Micro Cloud Architect will do the assessment and generate below documents/spread
sheet to be shared with ABC Ltd. technical team.

1. Solution Design Document

2. Test cases report spread sheet
3. Risk assessment report spread sheet
4. Security assessment report spread sheet
5. Migration tool report spread sheet
6. Migration cutover plan spread sheet

1.2 Audience

• ABC Ltd. Services technical team need to provide feedback of all the migration relevant
documents mentioned in section 1.1.
• Ingram Micro Cloud Solution Architect who prepare all the migration documents in detail and.
• Ingram Micro Sales can refer to the Migration plan and see the guidelines for any future
migrations.
 P age |5

1.3 Customer requirement

ABC Ltd. would like to move on-premise workload to Azure to solve the following
challenges:

• Increase the quality, transparency and efficiency of their end customers.

• Fulfill the need of the end user clients requiring storage of data in their own countries
• Non-dependable IT functions or provide clients with the expected speed and reliability
required to operate their businesses
• Azure Active Directory Integration
• Scalable PaaS solution for database with a SQL Server Agent, and Service Broker
• On-premises infrastructure cost is scattered across multiple areas. Electricity, internet
connectivity, cooling solution, security personnel etc.
• They also want to save cost which needs to keep on updating individual servers or
computers and installing new software licenses, cloud computing allows the IT team
to focus on using the cloud to better up business processes throughout the
organization rather than responding to employee needs.
• They also want to take advantage of CSP program which will bring down their
operational cost.

Below are ABC Ltd. Group Limited requirements gathered during assessment,
Business
Req. No Requirement
Priority
ABC Ltd. Group Limited has servers which needs to be upgraded
1 and cost associate to migrate to latest OS is significant, also avoid High
end of support costs (CSA)
2 Ensure there is no downtime, no disruption: by performing an OS
upgrade on a target clone, ABC Ltd. Group Limited source is never High
interrupted during the process
3 Take advantage of current offers from Ingram Micro CSP program Medium
4 Validate Upgrade to Target Clone to ensure Application
High
Compatibility with newer OS with no risk
5 Mitigate cybersecurity threats from unpatched OSs High
6 SQL Server Database for application should be swapped with
Medium
newer OS versions in Azure
7 All migration should happen during weekend – 3 PM to 11 PM High
8 All relevant existing documents should be moved into the new
repository and classified in accordance with the ABC Ltd. Group High
Limited defined attribute and security model
9 Consistent backups for guaranteed and simple recovery of virtual
machines
- Snapshot, copy & archive: incremental or full, 0-downtime
Incremental and archived backups to save storage space
Medium
- Daily incremental backup
- Weekly full backup
- MySQL binary logging of each transaction, daily full dump
to reduce time of replaying changes
10 Mitigated risks of failed recovery, recovery testing and automated
consistency checking after recovery
- All backup and restore functionality should be tested
Low
quarterly
- Alerts should be sent out should any backup or restore
tests fail.
 P age |6

11 RTO (Recovery Time Objective): 3days High

12 RPO (Recovery Point Objective): 1h for Git, 1d for JIRA and
Application High
- Zero data loss within RPO requirements
13 Encryption Policies
Data at rest:
Information at rest will be stored in Azure storage account so we
take advantage of it out-of-the-box features
Data in transit:
Any income/outcome data will be sent using an encrypted transport
High
layer (https)
- CLI
- Azure portal
Customer → Azure Storage Account (https)
Azure Storage Account → VM (https)
Azure Storage Account → RnD (https)
Table 2 Customer Requirement

1.4 Review and verification of customer requirements and

associated changes
• Ingram Micro Cloud Architect make sure to have detailed analysis of customer
requirements.
• Ingram Micro Migration team prepare a report and get verified with customer.
• Ingram Micro Migration team is responsible to make any associated changes after
customer reviewed.

1.5 Scope and business benefits

The following deliverables and business benefit from the project “SQL Database migration”.

Deliverables Business Driver / Benefit

Infrastructure Data software operational on Implementation meets the following business

the Azure platform benefit
• Create a CSP tenant and create Azure • As on-premise workload’s license is in EOL,
SQL server and SQL Managed instance (Windows Server, SQL) hence decided to
workload into it move to Azure
• Install 1 x DMA instance (On-premises) • On-premises maintenance cost (power,
and push the schema and database to electricity, security personnel etc.) will be
Azure SQL database. off.
• Create Database Migration Service in • Azure CSP – better pricing
Azure so that the data can be migrated • Meets Ingevity’s application high availability
over to SQL managed instance. requirement.
• Test and verification of the above task. • Meets Ingevity’s security requirement

Table 2 Scope and Business Benefit

 P age |7

1.6 Deployment Window Planning

The cutover date & time is confirmed and documented in the Solution Design Document with
considering for minimal business disruption. Common attributes considered are customer
business office hours, end user impact such as hours of access, day of week, holidays, and
critical business volume periods.

Scheduling Worksheet
Locale USA - Pacific Time Zone
Preferred Days of Week (MON-SUN) Saturday

Preferred Hours 6AM – 2PM

Monthly Preference Code Freeze NOV/DEC
Table 3 scheduling worksheet

1.7 Cost analysis

General purpose tier is available with:

• 8 cores: $736.29/month
• 16 cores: $1,472.58/month
• 32 cores: $2,208.87/month
A deployment comes with 32GiB of storage. Additional costs will include storage:
Capacity: Each 32GiB block, up to 8TiB, will cost $0.0575/GB
IOPS: Every 1 million requests will cost $0.10. Charging will start after Dec 30 th.
Backup storage: Will cost $0.05 per GiB. Charging will start after Jul 30 th.

1.8 Azure Naming Conventions

Customer advised an existing naming convention will be retained for this implementation.

1.9 Related Documents

SR# Details Document link / location

1. Microsoft Cloud Adoption https://docs.microsoft.com/en-us/azure/architecture/cloud-

Framework adoption/

2. Azure Database Migration https://azure.microsoft.com/services/database-migration/

Service
3. Ingram Micro operational https://confluence.int.zone/display/PM/ITSM+Management
docs
• Incident management
• Problem management
• Change management
• Capacity
management
 P age |8

• Service level
management
• Request fulfilment

Table 4 Related Documents

1.10 Roles and Responsibilities

Resource Contact details Responsibility

Co-ordinate with reseller IT

works and customer ABC Ltd..
Technical POC from Ingram
Micro Lifecycle Services
Technical POC from Ingram
Micro Lifecycle Services
Table 5 Roles and Responsibilities

2. Current architecture

ABC Ltd. has application and database servers deployed in multiple location in Australia. In
Australia east location Townville has the primary site where Australia southeast location Adelaide
has the secondary site.

2.1 Database Architecture

 P age |9

Figure 1 Existing on-premises architecture

2.1.1 Application Servers

Server Env. Server Name OS IP Core MEM NIC. C:\

Role address In GB
Virtual Prod. WebAppServer1 Windows X 4 16 1 50
Server 2016 GiB
Datacenter
Virtual Test/Q WebAppServer2 Windows X 4 16 1 50
A Server 2016 GiB
Datacenter
3. Table 6 Existing on-prem application servers’ inventory

2.1.2 Database Servers

 P a g e | 10

Type Env. Server OS SQL SQL IP Core Mem NIC C:\ D:\
Name Cluster Inst. address In Data
Name GB
Virtual DB DbServer1 Win SQLClus1 1 X 8 24 1 80 1 TB
2016 DC Gi
B
Virtual DB DBServer2 Windows SQLClus1 2 X 8 24 1 80 1 TB
2016 DC Gi
B

Table 7 Existing on-prem database servers’ inventory

3 Operational process

The Operations process focuses on techniques and approaches to adopt a cloud capability. Below are few
components to focus,

3.1 Service Management

3.2 SLA Strategy
3.3 Business Continuity Planning
3.4 Performance and Operational Health

4 Assessment
After having the customer workload details, Ingram Micro assesses workloads and creates an
assessment report to be produced to the customer. Below section has the assessment tools,
steps and assessment reports.

4.1 Assessment Tools

The following tools may be used to accurately assess the existing on-premise infrastructure
environment. The tool then produced a report which then will be presented to the customer. Also,
all inventory from the assessment report is documented here in the table below:

Tool Name Purpose

Database migration assistant (DMA) Used to migrate on-premise database to Azure SQL
managed instance (MI)

Table 8 Workload assessment tools

5 Proposed architecture
 P a g e | 11

ABC Ltd.’s on-premise SQL database will be moved to Azure CSP by deploying resources in
Australia East and Australia Southeast regions.

The following sums up high level proposed Azure architecture:

• Existing VMs will be migrated into Azure VMs using lift-and-shift methods.
• Azure default authentication service (AAD) will used for this tenancy within single region,
two availability zones.
• For application servers, a separate subnet will be created. Utility and reporting instances
will be deployed under same subnet.
• To protect against data centre failures, application server will be replicated using ASR to
another availability zone.
• To switch traffic from one availability zone to another availability zone (failover), manual
DNS method will be used. There is a requirement in future to leverage Azure traffic
manager to route traffic between primary and secondary regions – i.e. If primary regions
become unavailable, then traffic manager fails over to the secondary region.
• Two different IP subnets will be used for application and database servers excluding
gateway IP subnet for application gateway.
• Managed SQL instance will be used as data solution, existing data will be migrated in DB
instance and on-premises DB Server will scraped. Due to redundancy requirement, MI
VNET will be peer with another Azure MI region. The MI instance will sit in a different
VNET.
 P a g e | 12

• The application gateway firewall function will be used to protect the Application servers
for application level security. This will be in addition to Azure network security group
(NSG). The database servers will only allow traffic from application servers.

5.1 Solution Components

The Azure solution for this project has the following components and will be used within the
solution.

SR# Parameter Description

1. Resource group Resource groups are used to group resources so they can be
managed by a lifetime, owner, or other criteria.
2. Virtual network Every Azure VM is deployed into a VNet that can be segmented
(VNet) and into subnets. Create a separate subnet for each tier.
subnets.
6. Network security Use network security groups (NSGs) to restrict network traffic
groups (NSGs) within the VNet. For example, in the three-tier architecture shown
here, the database tier does not accept traffic from the web front
end, only from the business tier and the management subnet.
8. Virtual machines For recommendations on configuring VMs, see Run a Windows
(VM) VM on Azure and run a Linux VM on Azure.
9. Public IP address A public IP address is needed for the application to receive
Internet traffic.
11. Azure Monitor The azure monitor is used to collect all events and logs from
different parts of the infrastructure and the ID application to
allow an operations team to:
1. Monitor the usage of the whole system in real-time.
2. Store log data to aid root cause analysis and problem
identification
3. Alert operations when specific metrics have been
breached

Azure monitor stores data within a data warehouse and uses a

query language called ‘Azure Monitor log query’ to be able to
retrieve data. https://docs.microsoft.com/en-us/azure/azure-
monitor/log-query/get-started-portal
12. Azure Security The Azure security centre is a separate service that monitors
Center virtual machines and other Azure services looking for
vulnerabilities and exploits. Security centre raises events to
Azure Monitor.

13. Jumpbox Also called a bastion host. A secure VM on the network that
administrators use to connect to the other VMs. The jumpbox
has an NSG that allows remote traffic only from public IP
addresses on a safe list. The NSG should permit remote
desktop (RDP) traffic.
15. Availability sets Create an availability set for each tier, and provision at least two
VMs in each tier, which makes the VMs eligible for a higher
service level agreement (SLA).
 P a g e | 13

16. Load Balancer Use Azure Load Balancer to distribute network traffic from the
web tier to the business tier, and from the business tier to SQL
Server.
17. SQL Managed SQL managed instance is a deployment of Azure SQL database
Instance which provides automatic backup, patching etc.
Table 9 Propose Azure Solution Components

5.2 High Availability (HA) architecture

The auto-failover group is configured on the primary instance and will connect to the secondary
instance in a different Azure region. All databases in the instance will be replicated to the
secondary instance. The following diagram illustrates a typical configuration of a geo-redundant
cloud application using managed instance and auto-failover group.
However, the application gateway is configured in Australia East region only. The application is
not highly available for this reason. A manual process is implemented for DR situation.

5.3 Failover Scenarios

Figure 2 Failover architecture

5.4 Disaster recovery architecture

 P a g e | 14

With disaster recovery, Azure VMs continuously replicate from to a different target region. If an
outage occurs, you can fail over VMs to the secondary region, and access them from there.
When everything's running normally again, you can fail back and continue working in the
primary location.

Figure 3 Proposed disaster recovery architecture

5 Architectural review
• Ingram Micro Cloud Architect make sure to setup meeting with customer requirements and share
proposed architecture for review.
• Once Proposed architecture get verified by customer, Ingram Micro Migration team is responsible
to make any associated changes after customer reviewed.

6 Migration Strategy

Server Name Scope Tool

INGVSQL1 Rearchitect DMA, DMS
INGVSQL2 Rearchitect DMA, DMS
INGVSQL3 Rearchitect DMA, DMS
INGVSQL4 Rearchitect DMA, DMS
Table 10 Refactor, Rehost and Rearchitect

7 Configuration Parameters
 P a g e | 15

During the build phase, the following parameters will be enabled throughout all Azure components
to achieve the required solution to solve the business requirements.

7.1 Network Configuration

In a migration process, set up networking is one of the critical design steps. Below mentioned
point s are considered in a typical design process. The design document should consider the
points which are as under:

Topics Details

Virtual Network design existing vNET will be used for the VPN gateway
Design subnets add gateway subnet as per diagram 1 above
IP address planning, Setup DNS
Configure NSG nsg1 – existing will be used
Setup availability zones Australia east only
Design hybrid cloud networking yes – VPN site to site
Configure site-to-site VPN Yes
Configure vNET peering No
Configure Azure Virtual WAN No
Configure application security group No
DHCP, NTP & DHCP default Azure provided

Table 11 – Network Configurations

8 Risk Identification and Mitigation

The Risk Identification and Migration section of the Solution Design Document details the process
and company specific risks that need to be accounted for and mitigated in the solution design. The
number of risks and effects of each risk typically increases as a company moves down the scale
from their first few workloads in the cloud towards an all-in posture. It consists of four phases.
Step 1 – Identify
Step 2 – Assess
Step 3 – Mitigate
Step 4 – Enforce / Monitor
Attached is the risk management sheet.

Risk_Assessment_Fo
nterra.xlsx

9 Optimizing Workloads
 P a g e | 16

After Ingram Micro moves resources to Azure, they need to streamline them to improve performance,
and maximize ROI with cost management tools. Given that Azure is a pay-for-use service, it’s critical
for Ingram Micro to understand how systems are performing, and to ensure they’re sized properly.
Post-migration operation is performed by Ingram Micro to help the customer decrease the cost and
optimize the resources.
Ingram Micro provides decentralized automation capabilities to reduce costs. Features suggested
include:
• Auto-snooze Azure VMs based on low CPU.
• Schedule Azure VMs to snooze and un-snooze.

9.1 Azure Cost Management

• To make the most of their cloud investment, Ingram Micro will take advantage of the free
Azure Cost Management tool.
• Azure Cost Management provides simple dashboard reports to help with cost allocation,
showbacks and chargebacks.
• Cost Management can optimize cloud spending by identifying underutilized resources that
Ingram Micro can then manage and adjust.

9.2 Total cost of ownership (TCO)

On-premises cost (per Azure cost Difference(ratio)

month/year)
Server Cost ($100) $150 +$50
Electric cost ($20) 0 -$20
Storage cost ($20) $20 0
Maintenance cost ($50) 0 -$50
Network cost ($30) 0 -$30
-$50
Table 12 Cost Analysis

10 Secure and Managed

10.1 Secure Migrated Workloads

Securing workloads from threats is the most critical task after migration. Below security measures
can be taken to avoid internal and external threats.
Tasks Parameters

Follow Azure Security centre See security policy in section 6.1.1 to 6.1.3
recommendations.

Encrypt data (IaaS) Encryption can prevent from unauthorized access.

VM – use azure disk encryption.
Storage - Storage encryption is by default enabled for all
new. And can’t be disabled.
 P a g e | 17

Encryption data (PaaS) For Azure SQL database make sure data is encrypted using
Always Encrypted wizard of SQL management studio.
Protect the Azure SQL database with real time
VM antimalware protection Azure Security Centre generally reports about this
antimalware protection.
https://docs.microsoft.com/en-
us/azure/security/fundamentals/antimalware

Web Apps security Web apps can be secured using-

➢ Azure key vault which stores the app secrets and let
the application access.
➢ App Service environment which provides isolated
dedicated environment
➢ Web application firewall which comes with
Application gateway.
Review Subscription and Should review the IAM access for correct users to
resource access subscriptions and resources with correct RBAC.
Review audit and security logs Sign-in activity logs for who has logged in;
Multi-factor authentication
Table 13 Azure tools.

10.2 Manage Migrated Workloads

After securing the resources, the following features will be turned on to ensure workloads are
managed as standard to minimize the business risk.

Feature to be turned on Remarks

Resource delete lock on resource groups
Implement site recovery
Implement Access policy
Keep VMs into availability group for high availability,
VM management
use managed disk for ease of VM disk and storage
management.

Enable diagnostic logs

Business continuity and disaster recovery

Table 14 Policy – migrated workload management

11 Service Management Workflows

11.1 Problem/Incident Management

In the Hypercare period the team is available 24/7.

P1 issues Troubleshooting steps Contact if not resolved

 P a g e | 18

Connection to SQL There might be wrong Firewall Engineer

database fails configuration that’s why Azure
SQL database or client-side
firewall is blocking connections
to Azure SQL Database. For
that setup Firewall Rules to
allow Client IP address.
When an application This error occurs when the Engineer
connects to an Azure database is being moved (or
SQL database, and the reconfigured) and application
following error message loses its connection to the
is received: Error code database.
40613: "Database <x> Database reconfiguration
on server <y> is not events occur because of a
currently available. planned event (for example, a
Please retry the software upgrade) or an
connection later. If the unplanned event (for example,
problem persists, a process crash, or load
contact balancing).
customer support, and
provide them the
session tracing ID of <z>
Table 15 Refactor, rehost and rearchitect

11.2 Change Management

Below table has the change management topics that can be taken care if required

Topic Details

Changes can be absorbed Ad-hoc and minor changes will be absorbed if

the impact of change is less and efforts
required are less than couple of hours (2 – 3
hours)
Changes must go through process Any change after the sign-off of the
requirements and design, if impacting the
project timeline and effort will be notified to the
Customer. Any such change will go through
the change management process.
Cost and time impact If there is a change of scope at any stage of
the project from previously agreed baselines
(scope, timelines, deliverables), Service
Provider will assess the impact of such change
on the schedule and cost of the project.
Service Provider will raise a change request
for the estimated efforts, timelines, and cost.

Table 16 Change management

 P a g e | 19

11.3 Availability Measurement

High availability of the Azure services such that the SLA requirements are met

Azure Service System Availability (%) (24 x 365 basis)

Azure Sql Database 99.99 %

Azure App Service 99.99 %
Table 17 Availability measurement

Appendix A: Comments and Response

SR# Reviewer Reviewer’s comment Authors Response Open/
Name Customer / internal Closed
1.
2.
3.
4.
5.
6.

Table 18 Feedback – comment and response

Appendix B – Peer Review Process

The Solution Peer Review Process is detailed in this section.
 P a g e | 20

Figure Design Peer Review Process

Author of the design drafts the customer project specific design based on the Solution Design
Document template.
The document is peer reviewed for the following:

• The solution is fit for use as described in the requirements section of the Solution Design
Document
• The business and technical requirements are covered by the proposed architecture
• The business drivers are met by the solution
• That Best Practices have been incorporated and are fitting to the design, SLAs, and risk profile
of the customer
The review will either pass or fail the design based on the four success criteria. The solution must pass
all four criteria.
Failed criteria are documented in Appendix A and send back to the author for rework.