Migration to Huawei Cloud

Module 2: Migration Requirement Survey

 Objectives
⚫ Upon completion of this course, you will understand:
 Process of obtaining project information
 Pre-sales to service handover
 How to obtain the information required for migration design and implementation

2
 Huawei Cloud Migration Methodology – Project Preparation
Cloud Migration Framework
Discovery Planning Design Provisioning Migration Switching Aftercare

Roadmap Architecture Environment

Due Diligence Implementation Cutover Shadowing
Planning Design Readiness

Continuous operations
Collect the present Develop the migration Design the cloud Provision the target Implement the Perform a system Monitoring &
Engagement

state. strategy. architecture. environment. migration plan. Cutover. Health check

Design the Provision the
Clarify the migration
Formulate the operation model. Verify the
requirement. environment.
migration plan. migration result.
Design the security
model. Readiness
Validation
Design the landing
Assessment zone. Validate the target Confirmation Handover
environment.
Analyze requirement Solution Design Validate the Perform a business Deliverables
gaps. implementation acceptance test. handover
Design the implement
Assess the solution. process.
Knowledge
migration transfer
Design the validation Validate the cutover
feasibility.
solution. solution.

Project management
3
 Contents
1. Pre-sales to Service Handover

2. Pre-sales and Project Kickoff Meetings

3. Requirement Survey and Analysis

4. Cloud Migration Evaluation

4
 Effectively Transferring Information and Fully Disclosing Risks
During the Handover
⚫ The handover should focus on the overall project status, customer information, cloud migration solution, key contract content, and risk items. The most important thing is that
the pre-sales and service teams reach a consensus on the understanding of the handover materials and risks, which can instruct both parties in making continuous
improvement.

Customer information handover Cloud migration solution handover

The project BD shares customer- The project SA analyzes the designed
related information and issues solutions.
confirmed in early stages with the SA.
• POC test
• Customer's willingness to move to the • Source services and architecture
cloud • Private line solution
• Customer's manpower input Project information • Source information and destination
• Responsibility matrix products
• Communication matrix
handover • Destination cloud architecture
• Cloud migration scope The project BD and SA analyze the • Pre-sales information survey form
• Cloud migration objectives and delivery status, professional • …
milestones (start and cutover time) services, and product resources of
• … the project.

Contract handover Risk handover

The project BD and contract & The project BD/SA analyzes the solution
commercial manager analyze contract risks, delivery risks, acceptance risks, and
and commercial clauses. legal risks in pre-sales and provides
preventive measures.

The key to the handover is that the pre-sales and post-sales delivery teams reach a consensus on the changes in the project status, rights,
and responsibilities, and the subsequent actions brought by the changes.
5
 It's a Handshake Between the Pre-sales and Delivery Teams
⚫ EHO meeting to reinforce the handover and reach an agreement within the project team

⚫ Document meeting minutes for future reference

SENDING Typical roles in a service team
Project
Manager (some may not be involved):
Business Development (BD)
IT Architect (ITA)
Solution Architect (SA)
Technical Account Mgr. (TAM)
Consultant (on demand)
Customer Success Mgr. (CSM)
Others (on demand)
Partner Development Mgr.

Product Development Team

Others (on demand)

6
RECEIVING
 Recommended Pre-sales to Service Handover Checklist – (1)
Activity Description Handover Content Output Necessity
Delivery status: whether there is handover documentation
The project BD and SA analyze the Professional services: whether to purchase migration (or other) services
Delivery status, delivery
delivery status and professional
Project and service Product resource list strategy, and confirmed project
services of the project and
information handover Project estimation table estimation cost
describe the project estimation.
Decision and conclusion of the Sales Decision-making Team (SDT)
Customer's organizational structure, basic information about the customer's project
stakeholders, rights map, service map and architecture, technical verification result,
customer's migration willingness, solution information during the verification, Confirmed customer profile
correspondence, communication meeting minutes, memos, contracts, bidding materials,
The project BD shares customer- customer etiquette, taboos, etc.
Customer information related information and issues Decision on the cloud migration
Customers' willingness to move to the cloud
handover confirmed in early stages with the willingness
SA. Customer's manpower input Manpower input plan
Responsibility matrix Responsibility matrix
Communication matrix Communication matrix
Cloud migration scope Scope statement
Cloud migration objectives and milestones (start and cutover time) Milestone plan
Confirmed private line design
Private line solution
solution
POC test POC test result
Three confirmed pre-sales
Source services and architecture
charts
The project SA analyzes the Source information and destination products One confirmed pre-sales table
Solution handover
designed solutions.
Destination cloud architecture Confirmed cloud architecture
Pre-sales information survey form Information survey form
Confirmed high-level migration
Pre-sales high-level migration solution
solution
Main equipment and auxiliary material supply solution Confirmed solution

7
 Recommended Pre-sales to Service Handover Checklist - (2)

Activity Description Handover Content Output Necessity

Contract and commercial clauses

The project BD and contract & Billing and collection clauses

Contract content Confirmed contract
commercial manager analyze contract Upper limit and proportion of the penalty for breach of contract
handover handover document
and commercial clauses. Requirements for contract fulfillment and changes
Contract change and termination clauses
The project BD/SA analyzes the
solution risks, delivery risks,
Risk handover acceptance risks, and legal risks in Pre-sales risks List of confirmed risks
pre-sales and provides preventive
measures.

8
 Risk Authorization List in Sales Contracts and Risk Guidance

Risk Level Description

Once Clauses that involve violations of legal requirements and could probably bring major legal risks (involving significant
Prohibited
economic or criminal liabilities) to the company. Operations that violate such clauses must be stopped immediately.
Clauses and transactions that have company-wide impacts and could probably cause major legal risks, major goodwill
Significant
impacts, major operational security risks, or major business risks to the company during sales.
High The risk is difficult to manage; it can cause certain impact if takes place.
Medium
The risk is manageable under certain circumstance; it may cause some impact if takes place.
Low

9
 Contents
1. Pre-sales to Service Handover

2. Pre-sales and Project Kickoff Meetings

3. Requirement Survey and Analysis

4. Cloud Migration Evaluation

10
 Align Objectives, Organizations, and Responsibilities with the
Customer in the Project Kickoff Meeting
Objectives Organizations Responsibilities
Delivery scope and Responsibility
Organizational structure
objectives division

• Departments that the customer

• The delivery scope includes the • Organizational structure and needs to join, responsibilities of
scope and time limit of the stakeholders of the customer and each department, tasks involved in
migration to Huawei Cloud. service the migration, and the division of
responsibility

Project plan Working mechanism Risk alignment

• Milestones of the project, including • Regular meetings, communication

key nodes and objectives • Alignment of project risks and
frequency, progress reporting issues, which requires the
• Detailed project plan, containing requirements and frequency,
the sub-plan for each phase customer's assistance
information security, etc.

The kickoff meeting is a key step before the delivery phase. It aims to obtain support from the client's key stakeholders and enables the customer and
Huawei team to reach a consensus on the project objectives, schedules, resources, and others so that delivery can proceed smoothly.

11
 Customer's Leadership Must Attend the Kickoff Meeting and a
Consensus Must Be Reached with Them
organization

Engagement Kickoff preparation Invitation Kickoff Mtg minutes

Meeting

handover scheduling with the & Follow-up

customer activities

Service team
Customer team
Key attendants of the project kickoff

• Project BD
• Project sponsor • Project owner
• Project owner • Project sponsor
• Project manager • Solution architect
meeting

• Business owner • Project manager

• Operations owner • IT architects
• Support engineers • MSP

Key stackholders must be present at the kickoff meeting. Otherwise,

the meeting will fail.
12
 [Experience Sharing] Project Kickoff Meeting

Prepare Carefully Interactively Conclude Timely Follow Up Closely

• Communicate ahead, avoid • Present clearly in an • Highlight risks & support • Capture follow up actions.
surprised objection. interactive way. needed, gain consent from
client. • Ensure action owners are
• Collect questions before hand, • Collect questions and assigned correctly.
prepare answers.
suggestions in the meeting. • Align R&R.
• Actions shall be executable
• Confirm stakeholders'
participation in multi-ways. • Ceremonialism • Unify project goal & plan. and specific.
Invite ahead.
• Acknowledge process. • Review regularly until closed.
• Meeting materials should be
clear and clean.

Clarify the scope, goal and challenges, manage client's expectation, reach mutual agreement as much as possible before kickoff;
Prepare responses to anticipated questions or challenges; avoid involuntary commitment or diverging discussion in the kickoff mtg;
Invite technical members (SA/ITA) to interact technical questions, lead the detail technical discussion to offline dialog instead of kickoff mtg;
Document meeting minutes with mutual agreements and follow-up actions, distribute it timely as a kickoff artifact.

13
 Contents
1. Pre-sales to Service Handover

2. Pre-sales and Project Kickoff Meetings

3. Requirement Survey and Analysis

4. Cloud Migration Evaluation

14
 Application Status Survey Object – Three-Layer Survey Framework
⚫ The survey and analysis of the cloud migration status cover a wide range of content. The overall structure and layers need to be considered, and a
proper survey granularity is needed to provide necessary information for cloud migration design. Generally, the survey is performed in a top-down
manner (from services to resources).

Service panorama Output the business architecture

panorama.

L0 service panorama

Service Service architecture Service

architecture A B architecture X
Survey the application architecture to
Data Data output the solution for migrating
App architecture A App application systems to the cloud. The
architecture architecture
architecture B B solution contains the source
L1 application A … architecture, target architecture, and
system survey service system relationship.
Technical architecture A Technical
architecture B

Evaluate the resource functions and

L2 application ...resource performance satisfaction at the
component Compute Storage … component destination based on the resource
...resource ...resource
survey resource resource information usage at the source, and output the
component component
component component destination LLD.
information information
information information
The survey collects customers' pain points in source services and resources and explores customers'
requirements to help improve the benefits of migration and achieve win-win.
15
 Application of the Information Collected at Each Layer in Migration
Evaluation and Planning of Destination Environment Deployment
Survey Architecture and Solution Design
Application Migration to the Cloud and Test
• Cloud account management,
L0 service panorama Cloud migration policy planning
VPC...
L1 application architecture A Subservice architecture
Application architecture A
Data flow A • Cloud architecture design
Cloud migration batch planning Service deployment
• Switchover solution design
Technical architecture A
External association of application A
L1 application architecture... ... ... ... ...
L2 application component A Compute component information SMS

Storage component information OMS

Database component environment
• Cloud architecture design DRS
information Cloud service satisfaction evaluation
(detailed resource design)
Middleware component information • Migration solution design DRS

Big data component information CDM

L2 application component... Compute component information SMS

Storage component information Cloud service satisfaction evaluation OMS

Compute component information DRS

16
 [Experience Sharing] Survey Map: Easy to Hard, Continuous
Iteration
Who What How
Requirement Constantly collect
Customer's requirements
Easy
Business Overview;

Document
Public media;
Chief Architect Overall Application Landscape; Technical Common information; Given documents
Architect

Architecture;
Application Architect Business requirement;
Infrastructure Architect

Application dependencies;
App Dev

Development Owner 3rd party dependencies; Get from APM/CMDB

Data dependencies;
Application Developers

Tools
Compliance/DR requirement Generate by tools, ie. RDA

Check from source system

Infra Spt.

Infrastructure Owner

System Administrators Detail inventory;

Dialog
Application deployment mapping; Survey or forms
Direct conversation

Hard
17
 Application Status and Requirement Survey Path
Optional survey methods:
[Easy]: Obtain customer information from public channels (such as websites and WeChat official accounts) and previously obtained materials (such as pre-sales and system
documents).
[Medium]: Use tools (such as RDA) or obtain permissions (such as read-only permissions) to directly capture data from the source system.
[Difficulty]: Obtain information through daily communication with stakeholders, interviews, meetings, or questionnaires.

1. Specify the necessary information that required for achieving the

1. Specify milestones as your target.
objectives.

6. Conduct 2. Sync and go over the known info among the project
2. Go over
6. Proceed the action to clarify required due team. Avoid asking for the same information
known info.
information diligence. repeatedly.

Easy to Hard
Rough to Detail
Iteration
5. Consider the best approach to interact with
identified stakeholder. We shall spend the 5. Determine
3. Identify 3. Identify the information gap and the reason why it is
interaction
minimal effort to get the expected result. gaps. needed. Find out the best way to fill this gap.
strategy.

4. Confirm
stakeholder.
4. Determine who is the right stakeholder to contact when it requires
interaction with customer.

18
 Application Status Survey Methods
No. Method Scenario Advantages Disadvantages Easy
This method has little dependency on
1. Some information on the CMDB platform is outdated or
customers. The detailed resource list,
The customer has the CMDB platform inaccurate. After obtaining information, you must confirm
association between data layers, and
1 CMDB platform that contains the application invoking it with the customer in written form.
association between the data layer and
module. 2. Generally, association information cannot be exported
application layer can be directly obtained
in a batch on the CMDB platform.
on the GUI.
1. The agent needs to be installed on the customer's live
network, which is sensitive.
The detailed resource list can be obtained
2 RDA tool The customer agrees to install the agent. 2. Only a small amount of information can be obtained for
quickly.
databases and middleware, and the application invoking
relationship cannot be obtained.
The customer's business team is 1. The survey period is uncontrollable.
Manually fill in the survey
3 The customer has sufficient manpower. responsible for the resource list and 2. The accuracy and integrity of the obtained information
template.
application invoking relationship. is uncontrollable.
The access layer and application layer
The customer's service resource list,
information can be accurately obtained
4 Configuration file DNS/ELB/NAT export files, and gateway The application invoking relationship cannot be obtained.
based on the obtained customer
configuration files have been obtained.
information.
Text needs to be processed offline in This method improves efficiency and
Python and Java capabilities are required of the project
5 Script batches, for example, thousands of accuracy and reduces the manpower
team.
Nginx conf files need to be sorted out. required. Hard
By starting or stopping an application, you
The customer has a POC environment
can accurately observe the dependency
6 POC test and can restore scenarios in the The POC environment must be able to restore scenarios.
between the application and peripheral
production environment.
applications.

19
 [Experience Sharing] How to Prepare for the Survey
⚫ The survey is a continuous interaction and communication process that focuses on services and systems from the customer perspective. It determines
what to do, how to do it, and the least amount of information that is missing, and then makes up for the shortage.

Known input Survey objectives Customer roles: architect,

development/O&M owner, and
Development/O&M engineer

Handover meeting materials: Whether the migration positioning can be Customer:

• Customer and project determined based on the known project • What they want and do not want to do
information boundary, customer willingness, and • Who (customer or service team) is
• Pre-sales survey materials requirements: expected to execute the task
• Overall architecture design • How and when
• Migration without any change
• Known risks • Financial and business impact
• Tuning
• Contract clauses • Security and O&M system
• Advanced reconstruction
• …
Kickoff meeting conclusion and Whether the service status and technical
minutes: Systems:
information are sufficient for subsequent
• Organization • Service association
evaluation, planning, and design based on
• Division of responsibilities • Importance level
• Communication matrix customer requirements • Dependency and invoking relationships
• Communication mechanism • Migration environment evaluation and planning • System and deployment topology
• Consensus objectives • Target architecture evaluation and planning • …
• Follow-up tasks • Batch planning
• Migration and switchover planning and design
Other obtained materials

Business systems

20
 [Experience Sharing] How to Conduct a Good Survey
Survey team: SA, ITA, and delivery engineers

Know Your Customer Get Connection Build the Trust Apply Your Influence

1. Customer's
2. Customer's profile 3. Kickoff 4. Daily Routine 5. Key Milestones 6. Ask for Help
Business Success

• Study the business • Get familiar • Build the team • Roll out a conversation • Participate in • Acknowledge
information we • customers' org mapping with with each counterpart customer's daily customer's capability;
obtain about this structure, roles and customer's org. according to their technical share the perception
customer. individuals. • Establish linkages, profile/personality. challenges, that this is a joint
and confirm R&R demonstrate our effort.
• Identify the outdate • Summarize position- and counterparts. • Leverage events like expertise. • Show your
or missing influence matrix of tea-break or team counterpart's effort
information. stakeholders. building to make and value, express our
stronger connection gratitude when
reporting.

Customer relationship support

Key customer Organizational Extensive

relationship relationship relationship

21
 Contents
1. Pre-sales to Service Handover

2. Pre-sales and Project Kickoff Meetings

3. Requirement Survey and Analysis

4. Cloud Migration Evaluation

1. Platform
2. Applications

22
 Platform Readiness Assessment
⚫ Large-scale enterprise customers would like to have high-level platform architecture design for business case study when they migrate their
production workloads to Huawei Cloud.

Perspectives Understand Infra Services Mapping

▪ Services availability analysis
▪ Product features gaps analysis
1 Business ▪ License transfer / purchase
▪ Security compliance
2 Infra. Services

High-level Huawei Foundation Architecture

3 Networking
▪▪ Add Text
Multi Content
account structure for boundary permission and
4 Storage ▪ Add Text Content
resource management for multi tenant environment
▪ Add Text Content
Enforce minimal baseline best practices
5 Monitoring ▪ Secure production workloads running on Huawei Cloud

6 Logging Facilitate Business case

▪ Deliver accurate Bill of Material (BOM) to establish business

7 Security Control
▪ caseText
Add andContent
budget
▪ Add Text Content
8 DR & Backup

23
 Sample

24
 Contents
1. Pre-sales to Service Handover

2. Pre-sales and Project Kickoff Meetings

3. Requirement Survey and Analysis

4. Cloud Migration Evaluation

1. Platform
2. Applications

25
 [Methodological Experience] "Three Layers, Four Architectures,
and Six Factors" – (1)
⚫ According to due diligence result, sort out the 3 layers' overview: business overview, applications overview, and infra overview.

⚫ Drill one level down, complete the 4 architectures: Business architecture, Application architecture, Technical Architecture, and Data Architecture if there's Big-Data in scope. In
particular, tidy up the dependencies among applications, as well as infra components.

⚫ Analyze the present state together with customer's expectation or requirement by considering the 6 factors, summarize our key findings, then provide improvement
suggestions.

Input General Guidelines Expected Output

Due diligence Three layers, four architectures, six factors Key-findings & Improvement
result suggestions
Analysis Deliver
Public
information

Tools

Conversations

26
 [Methodological Experience] "Three Layers, Four Architectures,
and Six Factors" – (2)
Key Findings and Optimization Suggestions for a System
Requirement Analysis
Architecture Sub-item Key Findings
Dimension
The number of concurrent users is large, and the
Application architecture Performance Number of concurrent users
concurrent time fluctuates regularly.

Reliability Data dual-write The data dual-write function is not used.

Security Data audit The data audit function is not used.

Data architecture
Provide a The database uses read and write isolation. The
solution Read and write isolation
Scalability/Performance read/write ratio is uneven. Database/Table
Database/Table partitioning
partitioning is not used.

Reliability Cross-AZ HA Resources are deployed in CN East-Shanghai1.

Security Host security Security hardening is not performed on hosts.

Scalability AS AS is not enabled on some hosts.

Technical architecture
Resource specification The resource usage of some hosts is high, and the
Performance
improvement configuration needs to be optimized.
Automatic scaling is not used. If resources are
Cost Automatic scaling insufficient, manual intervention is required to
determine whether to perform a scale-out.

27
 [Case Study] Source Architecture and Key Findings (Application
Migration to the Cloud)
⚫ The following figure shows the technical architecture of a community system and order system. The access layer uses ELB and Nginx. Application servers are deployed on VMs. The cache uses
the Redis middleware. The Kafka message queues are used. The community system functions as a message producer, and the order system functions as a message consumer. The MySQL
databases are deployed in active/standby mode. The backup service is used to back up the databases, and the backup data is stored on the file server.

DDoS/WAF 3 Key Findings

Access layer

ELB (2 ECSs) 1 Availability:

ELB (2 ECSs) • The file server and backup server are deployed on two
Nginx (3 ECSs)
Nginx (3 ECSs) physical servers, respectively, which may become
Order system
faulty. The availability needs to be improved.
Community system
• The application system is deployed in a single data
1
Application layer

2 center without DR design. The availability needs to be

improved.
Merchant Partner service External service Distribution Order access Order query Order processing Order control
center service APIs
• The community system and order system share the
jobs jobs center
Redis cluster. If the cluster is faulty, both systems are
affected.
4 ECSs 5 ECSs 10 ECSs 9 ECSs 4 ECSs 3 ECSs 5 ECSs 7 ECSs Scalability:
2 • Application servers cannot scale resources on demand.
• The Redis cache service is deployed in active/standby
Middleware

mode. The memory size cannot meet requirements,

Active/Standby Producer Cluster and the scalability is poor.
2 Kafka server 1 Kafka server 7 Consumer
Redis Redis Improved security:
server 1 server 2 • The north-south traffic is cleaned by WAF and DDoS.
However, the east-west traffic cannot be isolated by
Active/Standby 3 the VMware virtualization environment, and internal
Active/Standby
threats cannot be blocked.
Data layer

MySQL MySQL
MySQL MySQL Backup Backup

1
File server 1 Backup server 1

28 Document storage Backup

 [Case Study] Source Architecture and Key Findings (Big Data
Scenario)
On-premises big data clusters
Interface service Data analysis service CDP customer service platform BI report platform

Key Findings on the Source

Result data layer

Elasticsearch
Presto Oracle Redis cluster Fine BI
cluster Availability:
No backup mechanism is available. Data cannot be
Real-time compute restored if it is lost or deleted by mistake.
Offline Hadoop cluster cluster
Hive Impala HBase
Flink Scalability:
Compute service

ZK Yarn Sentry The scale-out efficiency of the on-premises IDC

Spark Vertica cluster solution is low. Generally, the scale-out period is long.
layer

Solr Spark

Performance:
Sqoop
HDFS The Vertica table structure uses the longest varchar
length. As a result, the memory usage is high and SQL
performance deteriorates.
Collection
layer

Kafka Java Sqoop FTP Python parsing Cost:

The CPU and memory usage of the source cluster is
low, causing resource redundancy and waste.
Source data
layer

MongoDB
Platform

External
Hadoop

MySQL
Sensors

cluster

Oracle

server
data
Data

Data
data
Log

SQL

29
 [Case Study] Advertising Service of a Project – Technical
Architecture 1 Key Findings and Optimization
App/PC/Intelligent terminal External DNS
Suggestions
Access layer
LB Access layer: There are many traffic paths, which need to be
normalized.
• The main access modes include DDoS and SLB. Three Nginx
3 Private DNS clusters are used as access gateways.
DDoS WAF core-proxy data-proxy ad-proxy Application layer: multiple versions and deployment modes,
poor elasticity
Application layer • Services are deployed in three Kubernetes clusters. About
k8s-s k8s-w 2 4 50% services on the ad server have been containerized.
Ad cluster merge (ack 1.18.8) ECS
(v1.14.5) (v1.14.5) Services that have been put into commercial use are not fully
go-mye-api ad-finance containerized.
go-advertise h5z
Data layer: The Codis version stops evolving, and the
my-adx mye-api CTR/CVR my-ad-promotion-manager
jze Cronjob availability needs to be enhanced.
Advertising my-dsp-agent • The data layer contains Kafka, Codis, ES, HBase, and MySQL
my-ad-promotion C interface my-ad-open material anti- my-ad-de
manage-crontab clusters, all of which are built based on ECSs.
copying Big Data & AI: multiple components with the same function
Insurance-api Local-service ad-finance-api manage-
advertise and varied architecture
Ad-recall-server manage-report • Big data clusters include MaxCompute and on-premises CDH
clusters. AI training platforms include the on-premises
Data layer platform, PAI, and Pangu.

Kafka clusters (2) Codis (6) ES (1) HBase (1) MySQL (1) MongoDB (1)
1 Availability: Improve availability and deploy key
Big data & AI components across AZs.
Data
2 Performance: Improve resource specifications by 50%.
Data ingestion Data development governance Data sharing Model training Security: Enhance border and application security.
3 Cost: Reduce the O&M cost by XX. Migrate services to
flume Real-time CDH Flink Platform T HBase Pangu
4 the cloud. Combine and unify components and
On-premises architectures.
Kafka Offline CDH Spark Streaming Platform B ES
platform
DI synchronization MaxCompute storm DataWorks Da Vinci (BI) PAI

30
 [Methodological Experience] Application Status and Requirement
Survey – Association Analysis
• The association survey is required mainly for batch migration, partial migration (only some services are migrated), and system integration verification.
• The sub-service system is used as the survey granularity. The association between systems, components, and microservices in the sub-service system does not need to be surveyed.
• Pay attention to not only the invoking dependency between systems, but also the dependency generated by the database, middleware, and synchronization tasks.

Communication dependency between applications Shared data dependency

Start

Register a service with the

survey center, such as DNS,
Subsystem dependency Database dependency DTS real-time synchronization
Eureka, and Consul. The MQ dependency analysis
analysis analysis analysis
system invokes the service
through the URL or service
name.

Register a service Yes

with the survey Invoke No No DTS source or No
center? databases of Producer? destination … End
Sorting methods: other systems? database?
1. Configuration analysis Sorting methods: Methods:
(Manually view/compile script No 1. Configuration analysis Methods:
1. Configuration analysis
scanning code.) Yes 2. Consumer information Yes Synchronization task Yes
2. Database user analysis
2. Call chain analysis No analysis information analysis
Invoke the IP
address?
Sort dependent services. Sort consumer services. Sort dependent services.
Yes

Sort out IP services and dependent

services.

31
 [Methodological Experience] Association Analysis Methods

Sorting and Analysis

Survey Phase Description
Method
Sort out the configuration file and configuration center of each subsystem, and output the
Communication Configuration analysis dependency between the subsystems. Alternatively, enable automatic script scanning based on
dependency between rules.
applications Sort out the invoking information (call chains and logs) of business systems to determine the
Call chain analysis
systems or IP addresses that invoke the business systems.
Sort out the configuration file and configuration center of each subsystem, and output the
Configuration analysis databases and middleware of other systems on which each subsystem depends. Alternatively,
enable automatic script scanning based on rules.
Consumer information Analyze the home system of consumer information (such as the channel and queue), and further
Shared data analysis improve and verify the dependencies sorted out by the global configuration sorting method.
dependency Analyze all the DTS real-time synchronization tasks at the migration source, analyze the source,
Synchronization task
destination, and synchronized databases, sort out the relationships between systems, and add
information analysis
the dependencies sorted out by the global configuration sorting method.
Analyze the system to which the database username belongs, and further improve and verify the
Database user analysis
dependencies sorted out by the global configuration sorting method.

32
 [Experience Sharing] Cloud Migration Feasibility Evaluation
Cloud migration

A C Solution for migration from A to B

B
Source Destination

Cloud migration feasibility

evaluation

Migration risk evaluation Cloud service satisfaction evaluation

• Object: C • Object: B
• Content: What are the risks in the • Content: Can Huawei Cloud provide the
migration from A to B? architecture required by B?
• Dimensions: tool, solution, • Dimensions: functions, performance,
environment, downtime, and availability, scalability, security, and cost
manpower input

33
 [Experience Sharing] Cloud Migration Risk Evaluation
Compute Whether HW Cloud offers similar services that can fulfill the needs, such as
Network Functionality
& Storage Cloud Prometheus service on other Hyperscaler

Whether the performance of our service, such as TPS/QPS of dataset, meet

Performance
customer's expectation

Monitoring, Database
Ops & & Whether we have the demanding service available in target region(s), such
Bigdata Availability
Maintenance as to accomplish multi-AZ deployment for DR

Whether we have sufficient resources in target AZs, such as some certain

Resources
flavors of ECS, or particular types of DB
Security & Middleware &
Compliance Deployment
Process

Input Output
Cloud Readiness
Key Findings Analysis Cloud Readiness Report
Requirement clarification
Look for R&D support
for not-ready services

34
 [Typical Risks] Cloud Migration Risks and Countermeasures
Evaluation
No. Common Scenario Countermeasure
Dimension
1. Consider using an open-source tool or a partner's migration tool.
1 Migration tools Huawei does not provide an automated migration tool.
2. Contact R&D engineers to output automated scripts for migration.

The migration solution is new. It has not been used 1. Contact R&D engineers to verify the migration solution.
Migration solution
2 before and has not been verified by the R&D lab. 2. Verify the migration solution in a test environment on the live network.

1. Build a dedicated network to significantly improve network stability and accelerate migration.
2. Migrate data by offline import and export, which reduces the dependency on the network. In
1. The network for migration is unstable.
this case, you must manually add incremental data. This method applies only to systems that have
Implementation 2. The migration link does not support reverse
no requirement on the downtime.
3 environment synchronization. Therefore, rollback is not supported.
3. Create database C and establish a reverse synchronization link from database B to database C
so that you can perform a rollback when the migration from database A to database B fails.

1. Check whether the customer's system has no downtime window.

Switchover time
The customer's system requires zero downtime. 2. Check whether the customer's system architecture meets the zero downtime requirement,
4 window
and communicate with the customer about the reconstruction workload.

1. The customer cannot coordinate system

1. System development/O&M ISVs must be coordinated. Otherwise, risks are uncontrollable.
Manpower development/O&M ISVs.
2. Service verification personnel before and after the migration must be coordinated.
5 satisfaction 2. The customer cannot coordinate migration
Otherwise, risks are uncontrollable.
verification personnel.

35
 [Experience Sharing] Cloud Service Satisfaction and
Countermeasures
Evaluation
No. Common Scenario Countermeasure
Dimension
Scenario 1: Develop a general cloud migration template for promotion or best
practices.
Scenario 1: Cloud services can fully meet the target architecture requirements. Scenario 2: Urge the corresponding product department to develop the
Scenario 2: Cloud services (such as DCS) are compatible with source features. mandatory features that hinder the project progress; manage customer
1 Function
Scenario 3: Cloud services (such as LTS) lack some capabilities and cannot meet requirements in a expectations and operations.
short term. Scenario 3: Persuade the customer to use other services, and ask the cloud
service (product department) to provide workarounds and a plan to bridge the
gap.
Scenario 1: The customer's application system has requirements on MySQL performance. The Scenario 1: Coordinate with the Huawei Cloud service product line to tune
POC test shows that Huawei Cloud MySQL service does not meet requirements. parameters.
2 Performance
Scenario 2: After parameter tuning, the Huawei Cloud service still does not meet requirements of Scenario 2: Analyze and optimize the application system architecture, such as
the customer's application system. horizontal expansion of the application layer and database read/write isolation.
Scenario 1: The application system needs to be deployed in active-active mode, but the
evaluation shows that the architecture of the application system does not meet the active-active
deployment requirements.
Scenario 2: The application system needs to be deployed in active-active mode and the Scenario 1: Coordinate with the cloud service product line to tune parameters.
3 Availability application system architecture meets the active-active deployment requirements, but the Scenario 2: Analyze and optimize the application system architecture, such as
evaluation shows that the resources of a Huawei Cloud service do not support cross-AZ active- horizontal expansion of the application layer and database read/write isolation.
active deployment.
Scenario 3: All the components of the application system require the DR capability, but the
evaluation shows that a Huawei Cloud service does not support DR.

Scenario 1: The application system requires cloud phones, but the evaluation shows that no cloud
phone is available in the region selected by the customer. Scenario 1: Switch to another region.
4 Resource
Scenario 2: The resources of a service in the region of the application system can meet the Scenario 2: Promote the Huawei Cloud service to expand resources.
current requirements, but cannot scale to meet the requirements in high concurrency scenarios.

Tips: There is no optimal, but the most appropriate solution which is determined by customer requirements.
36
 Thank You.
Copyright© 2023 Huawei Technologies Co., Ltd. All Rights Reserved.
The information in this document may contain predictive statements including, without
limitation, statements regarding the future financial and operating results, future product
portfolio, new technology, etc. There are a number of factors that could cause actual results
and developments to differ materially from those expressed or implied in the predictive
statements. Therefore, such information is provided for reference purpose only and
constitutes neither an offer nor an acceptance. Huawei may change the information at any
time without notice.

37