Cloud Migration: What to Know Before You Start

Cloud migration can look deceptively simple:

Move the servers out of your current data center, run them in the cloud, and move on.

But the difficult part is rarely the transfer itself.

The more important questions come before it:

What should actually move?

What should stay where it is for now?

Which workloads only need to be relocated, and which ones need to be redesigned?

What will the new environment really cost?

What happens if the cutover fails?

And once the migration is complete, who is going to operate the new environment?

AWS, Microsoft, and Google all make the same point in their official migration guidance: before moving workloads, you need to understand the current environment, map dependencies, prepare the target architecture, and build a migration plan.

The cloud does not automatically fix architectural, security, or operational problems.

Sometimes it simply moves those problems to a new address.

Start With Why You Want to Move to the Cloud

“We want to move to the cloud” is not a business goal.

Before choosing a provider or architecture, define the outcome you expect from the migration.

For example:

• Do you want to reduce hardware procurement and maintenance?
• Do you need more capacity during traffic spikes?
• Is your current disaster recovery setup not good enough?
• Does provisioning a new environment take too long?
• Do you want to use managed services?
• Do multiple branches or teams need access to shared infrastructure?
• Or has your current data center simply stopped keeping up with the business?

The reason matters because it changes the migration strategy.

If scalability is the main goal, simply moving a few virtual machines may not create much value.

If the priority is to leave a data center quickly, Rehost might be exactly the right decision.

If the real problem is an old application that is difficult to maintain, some modernization may need to be part of the plan.

Before choosing a cloud, define why you are going there.

Do Not Move Everything Just Because You Can

One of the most important cloud migration decisions is determining what should happen to each workload.

AWS commonly groups these choices into the 7 Rs.

Rehost

The application moves to the cloud with very few architectural changes.

This is often called Lift and Shift.

It can be fast and low-risk, but it usually does not take full advantage of cloud-native capabilities.

Replatform

The application moves, but selected components are improved during the migration.

For example, a database running on a virtual machine might be moved to a managed database service.

The application is not completely rewritten, but some operational responsibility is reduced.

Refactor or Re-architect

The application architecture changes to take greater advantage of cloud capabilities.

This can improve scalability and flexibility, but it usually requires more time, engineering effort, and cost.

Repurchase

Instead of continuing with the existing software, the business replaces it with a SaaS product or another commercial solution.

Retain

The workload stays where it is for now.

This may be the best decision because of cost, technical constraints, compliance requirements, dependencies, or simply low migration priority.

Retire

The system is no longer needed and is decommissioned.

This is more valuable than it sounds.

Cloud migration is often a good opportunity to find servers and applications that have been running for years simply because nobody ever made the decision to turn them off.

Relocate

Infrastructure is moved with minimal changes to the workloads, often in specific virtualization scenarios.

The important point is this:

Do not choose one R for everything.

Your CRM might be Replatformed.

A legacy application might stay under Retain.

Several VMs may be Rehosted.

And an unused internal tool may be Retired completely.

Good cloud migration is rarely one big decision.

It is a collection of workload-by-workload decisions.

Build a Real Inventory Before You Migrate

If you do not know what you have, you cannot plan how to move it.

An inventory should be more than a server list.

For each workload, you should understand at least:

• What the system does
• Who owns it
• Whether it is production, development, or test
• Which servers, databases, and storage systems it uses
• What data it stores
• CPU, memory, storage, and network usage
• Required SLA
• Backup and disaster recovery requirements
• Software and license dependencies
• Which other systems connect to it

Microsoft’s Cloud Adoption Framework recommends assessing architecture, performance, security, code, databases, and workload dependencies before migration.

Google Cloud also places discovery and inventory building among the earliest migration stages.

It may not be the most exciting part of cloud migration.

It is often the part that prevents the most expensive surprises.

Find Dependencies Before Cutover, Not After

Imagine you migrate an application server.

Everything looks healthy.

Then you discover the application still depends on an on-premises Active Directory server for authentication.

A scheduled job needs access to a file server that was not included in the migration plan.

The database only accepts traffic from certain IP ranges.

Or another application reads directly from the same database every night.

These dependencies do not always appear in a basic server inventory.

Dependency mapping should identify relationships involving:

• Applications
• Databases
• APIs
• File shares
• Identity
• DNS
• Firewall rules
• External services
• Scheduled jobs
• Message queues
• Monitoring
• Backups
• And network communication

Dependency mapping also affects migration order.

If three applications depend on the same database, they may not be suitable for three completely independent migration waves.

This is why discovery and dependency mapping should happen before wave planning.

Prepare the Landing Zone Before Moving Workloads

A common mistake is to start creating virtual machines first and decide on governance later.

The target environment needs a foundation before production workloads arrive.

This foundation is often called a Landing Zone.

A landing zone is not just a network.

Depending on the organization, it may include:

• Identity and access management
• Account or subscription structure
• Network architecture
• VPN or hybrid connectivity
• DNS
• Firewalls
• Logging
• Monitoring
• Security baselines
• Policies
• Encryption
• Resource naming
• Tagging
• Backups
• Budget controls

Microsoft defines landing zones as the foundation for governance, security, and scale in cloud environments.

That means before the first production server moves, you should already know:

• Who has administrative access?
• Who only has read access?
• Where do logs go?
• How are resources tagged?
• Are budget alerts configured?
• What is the backup policy?
• How are production and test environments separated?

Without governance, a flexible cloud environment can become a very expensive storage room surprisingly quickly.

Do Not Compare Cloud Cost With the Price of One VM

Pay-as-you-go is one of the biggest advantages of cloud computing.

It is also one of the reasons cost can become harder to predict.

The real cost of a workload is not just compute.

Depending on the architecture, you may also need to account for:

• Storage
• Backups
• Snapshots
• Databases
• Load balancers
• Public IP addresses
• Network traffic
• Data transfer and egress
• Monitoring and logging
• Security services
• Support plans
• Managed services
• Licensing
• Disaster recovery
• And the time required from the operations team

This is why official migration frameworks often focus on Total Cost of Ownership, or TCO, rather than simple VM pricing.

Sizing should also be based on actual usage, not only current hardware capacity.

If an on-premises server has eight CPU cores, that does not automatically mean it needs eight vCPUs in the cloud.

The server may have been oversized for years.

Cloud economics work best when resources are sized around real demand and continuously optimized after migration.

Build Security In From Day One

The cloud does not secure your environment automatically.

The provider protects the cloud infrastructure itself, but the way your organization uses cloud resources still matters.

Before migration, you should already have answers to questions such as:

• Who can access the environment?
• Where is MFA required?
• How are permissions restricted?
• How are service accounts managed?
• Where are secrets stored?
• How is data protected in transit and at rest?
• How is the network segmented?
• Where do security logs go?
• What is the incident response process?
• And are there compliance or data residency requirements?

Microsoft’s Cloud Adoption Framework recommends integrating security throughout the adoption process instead of treating it as something added after deployment.

Your landing zone should include guardrails so that every future workload starts from a minimum security baseline.

Check Data Residency and Compliance Early

Not every type of data can be moved to every region or provider without review.

Financial information, personal data, health records, contractual information, or industry-regulated data may come with specific requirements.

Before migration, define:

• Where the data will be stored
• Where backups will be stored
• Which certifications or compliance requirements apply
• Which data must be encrypted
• And what retention or deletion policies are required

If these questions only appear after the architecture is complete, part of the design may need to be rebuilt.

Measure Current Performance Before You Move

If you have no baseline, you cannot tell whether the migration improved anything.

Before migration, record the current behavior of the system.

Useful metrics may include:

• Response time
• CPU
• Memory
• Disk IOPS
• Network throughput
• Database latency
• Peak traffic
• Concurrent users
• Error rate
• Availability
• And execution time for critical jobs

After migration, measure the same metrics again.

That comparison matters far more than saying:

“The system is now running in the cloud.”

A migration is successful when the workload performs according to business requirements in the new environment.

Define RTO and RPO Before Designing Backups

“We have backups” is not enough.

Two important questions need clear answers.

RPO — Recovery Point Objective

How much data loss can the business tolerate?

Five minutes?

One hour?

One day?

RTO — Recovery Time Objective

If the system becomes unavailable, how quickly must it be restored?

Five minutes?

Two hours?

One day?

The answers determine how backup, replication, and disaster recovery should be designed.

An accounting platform and a static archive site probably do not need the same DR strategy.

Define the requirement before selecting the technology.

Never Plan a Critical Cutover Without a Rollback Plan

Google Cloud’s migration guidance specifically recommends creating and testing rollback strategies before they are needed.

Imagine the cutover night.

• Data synchronization does not finish.
• Performance is worse than expected.
• DNS does not update correctly.
• Authentication breaks.
• An integration stops working.

The professional question is not:

“What if something goes wrong?”

It is:

At what point do we decide to go back, and exactly how do we go back?

For critical migrations, define in advance:

• Go / No-Go criteria
• Who makes the final decision
• Maximum acceptable time for each stage
• When rollback must begin
• What happens to data created in the target environment
• How long the source environment remains available

A rollback plan should not be invented at 2 a.m. during an outage.

Do Not Start With the Most Critical System

A pilot exists to help you learn.

Your first workload should be realistic enough to test the migration process, but not so critical that every small issue becomes a business emergency.

A good pilot can help validate:

• Migration tooling
• Downtime
• Performance
• Security
• Cost
• Connectivity
• Operational processes
• And rollback

It also reveals whether:

• Discovery was accurate
• The landing zone is complete
• Automation is needed
• There are skill gaps in the team
• Runbooks are complete
• And actual migration time matches the estimate

The next wave becomes better because the first one taught you something.

Migrate in Waves

For larger environments, a big-bang migration usually increases risk.

It is usually better to group workloads into logical waves based on criteria such as:

• Dependencies
• Business criticality
• Complexity
• Environment
• Migration strategy
• Application owner
• Technology stack

Smaller waves reduce the impact of mistakes.

More importantly, every wave creates lessons that improve the next one.

Do Not Underestimate DNS and Networking

Sometimes the application migrates successfully.

The database works.

The infrastructure looks healthy.

And the cutover still fails.

Because of:

• DNS
• Routing
• Firewall rules
• Latency
• VPN
• Load balancers
• Certificates
• Or caching

Network and DNS validation should be part of the migration plan, not a final detail.

This becomes even more important in hybrid scenarios.

An application may already be in the cloud while the database is still on-premises.

Identity may still depend on internal Active Directory.

In these cases, connectivity between the two environments becomes part of the production architecture.

Do Not Forget the Operations Team

Migration does not end when the final VM starts successfully.

Someone still needs to operate the environment.

They need to monitor it.

Respond to alerts.

Validate backups.

Handle incidents.

Control cost.

Apply patches and security updates.

And maintain runbooks.

Cloud migration changes infrastructure.

It should also change the operating model when necessary.

If the operational process remains exactly the same, you may have changed the location of the servers without changing how the infrastructure is actually managed.

Optimization Starts After Migration

Go-live is not the end.

Once the workload runs in the cloud, you finally have real usage data from the target environment.

That is when optimization begins.

You may discover that:

• A smaller instance is enough.
• Storage tiers should change.
• Auto Scaling makes sense.
• A database should move to a managed service.
• Log retention should be adjusted.
• Unused resources can be deleted.
• Reserved capacity may reduce cost for predictable workloads.
• Or a system that started as Rehost can later become Replatformed.

A practical path is often:

Migrate → Optimize → Modernize

Sometimes it is better to move a workload quickly with limited change, stabilize it, and then modernize selected parts with better information.

Cloud migration is not one cutover.

It is a process.

Do Not Shut Down the Source Environment Too Early

After migration, there is often pressure to decommission the old environment quickly, especially because running both environments costs money.

But the source should only be retired when clear conditions are met.

For example:

• All target workloads have moved.
• Data integrity is confirmed.
• Backups and disaster recovery are tested.
• Performance is within the expected SLA.
• No unresolved dependency still points to the source.
• Monitoring shows no unexpected traffic reaching the old environment.
• And the required stability period has passed.

Decommissioning should follow criteria, not excitement after the first successful day.

Cloud Migration Checklist

When Should You Not Move to the Cloud Yet?

Cloud services can be useful for almost every organization.

That does not mean every workload should move right now.

Migration may not make sense yet if:

• The application depends on specialized hardware.
• The vendor does not support cloud deployment.
• Data residency requirements block the move.
• Ultra-low latency to on-site systems is essential.
• The target environment costs more than the migration is worth.
• The application will be retired soon anyway.
• Or the team is not yet ready to operate the cloud environment.

Retain is a valid strategy.

Sometimes the right migration decision is not to move faster.

It is to know what should not move yet.

Final Thoughts

Successful cloud migration does not begin with creating the first virtual machine.

It begins with understanding what already exists.

You need to know what you have, why it should move, what depends on it, and which migration strategy makes sense for each workload.

Then you prepare the target foundation:

Identity.

Networking.

Security.

Governance.

Monitoring.

Backups.

Cost controls.

Then you pilot.

Move in waves.

Keep a rollback path.

And optimize after go-live.

Cloud can make infrastructure more flexible, scalable, and easier to evolve.

But there is still one thing it does not do for you:

It does not make the architecture decisions on your behalf.

←Back to articles