Cloud migration architecture: assess, move in waves and cut over
Migrating to the cloud means moving the servers, databases and files that already run your business, with as little disruption as possible. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and how to move in safe steps.
Quick answer
A cloud migration first discovers what you run, how it connects and what it costs, then builds a secure landing zone and a private link to it. Servers are replicated with a migration service, databases are copied with change replication, bulk files move over the network or on devices, and each wave is tested and cut over.
| Best for | Moving existing servers, databases and files to the cloud, or leaving a data centre, with limited downtime |
|---|---|
| Less suited when | Building a brand-new app, where you can design for the cloud from the start instead |
| Start with | A full inventory, a landing zone, a private link and one low-risk application as a pilot wave |
| Main services on AWS | AWS Site-to-Site VPN, AWS Organizations, AWS Database Migration Service, AWS DataSync, AWS Transform, AWS Application Migration Service |
| Main services on Azure | Azure VPN Gateway, Management groups and Azure Policy, Azure Database Migration Service, Azure Storage Mover, Azure Migrate |
| Main services on Google Cloud | Cloud VPN, Resource Manager, Database Migration Service, Storage Transfer Service, Migration Center, Migrate to Virtual Machines |
The idea in plain words
Most migrations are less about technology than about order. You first need to know what you have: which servers, which databases, what talks to what and who depends on it. Without that list, a move breaks things nobody knew were connected.
Then you build the destination before you move: a secure landing zone, a private link between your site and the cloud, and the migration tools. Applications move in groups called waves, starting with a simple, low-risk one. Each wave is copied while the old system keeps running, tested in the cloud, then cut over in a short planned window, with a way back.
Moving as is, called lift and shift, is quickest. Changing the application on the way costs more now and usually saves more later. Decide per application, not once for everything.
The architecture
Boxes show the job each part does. Pick a cloud to see the service for each job.
Step by step
- Discover what you runScan or list every server, database and file store. Record sizes, software versions, traffic, who owns each one and what depends on what. This map drives every later decision.
- Choose a path for each applicationPick per application: move as is, change a little on the way, switch to a ready-made service, rebuild, retire it or leave it where it is. Group applications into waves, simplest first.
- Build the landing zoneCreate the accounts, sign-in, network, logging and budgets that the moved systems will use, before anything arrives. See the secure cloud foundation pattern.
- Connect the networksLink your site and the cloud with an encrypted tunnel or a dedicated line, sized for the copy traffic. Pick address ranges that do not overlap, so systems in both places can talk to each other.
- Replicate and syncCopy servers with a migration service that keeps them in step with the live system. Databases copy their data once, then stream changes continuously. Large file stores travel online, or on shipped devices when the network would take too long.
- Test, then cut overStart the copies in the cloud without disrupting users and test them against real cases. Then switch in a planned window: stop writes, finish the sync, change DNS and watch closely, keeping the old system ready for a quick return.
- Tune and retireAfter a stable period, right-size the servers, set backups and monitoring, adopt cloud services where they pay off, and switch off the old systems so you stop paying for both.
Services side by side
The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Connect your office or data centre (VPN or dedicated line) |
|
|
|
| Multi-account setup and governance (landing zone) |
|
|
|
| Migrate a database to the cloud |
|
|
|
| Move large amounts of data to the cloud |
|
|
|
| Discover, assess and plan a migration |
|
|
|
| Lift-and-shift servers to the cloud |
|
|
|
| Backup and restoreOptional |
|
|
|
| Move VMware workloadsOptional |
|
|
|
Each cloud offers its own migration tools, and the assessment, server and database tools are designed to work together. Check which source systems and versions each one supports before you choose.
Common variations
- Many VMware servers. Use a managed VMware service in the cloud to move virtual machines without changing them, then modernise at your own pace. Check each provider's current offer.
- Databases with a different engine. Convert the schema and code with a conversion tool, copy the data, test queries carefully and plan a longer window than for a same-engine move.
- Very large data or a slow link. Calculate the transfer time first. If the link would need weeks, use a physical transfer device or a dedicated line for the first copy and sync the rest online.
- Systems that cannot leave yet. Keep them in place and connect them to the cloud, or run cloud services in your own site with a hybrid product while you plan the next steps.
Move as is, or change the application on the way?
Each application can be moved as it is (rehost), moved with small changes such as a managed database (replatform), or rebuilt for the cloud (refactor). The right choice depends on time, budget and what the application is worth.
Move as is (lift and shift)
Good
- Fastest, with the least change and risk
- Frees a data centre or contract quickly
- Teams keep working the way they know
Watch out
- Brings old costs and limits along
- Often over-sized for cloud pricing
- Savings come later, after tuning
Change it on the way
Good
- Uses managed services and scaling
- Lower running cost over time
- Fixes old problems while you are there
Watch out
- Needs development, testing and time
- More risk during the move
- Costs more up front
Keep in mind
- Know your dependencies. A server that looks idle may be the one a monthly job needs. Watch traffic for a full business cycle before you decide, and ask the owners what they know.
- Time to move data. Divide the data size by your real, shared bandwidth. At full use, 100 TB over a 1 Gbps link takes about nine days, and real links are slower. Start the first copy early and keep it in sync.
- Plan the cutover and the way back. Write down each step, who does it and when, rehearse it, and agree the point after which you will not go back. Test the rollback, not just the move.
- Licences and support. Some software is licensed by site, core or cloud. Check the licence terms before moving, and confirm the vendor supports the software on your target cloud.
- Security during and after. Encrypt the copy traffic, limit who can run migration tools, remove temporary access when you finish and rebuild the controls that lived in the old network, such as firewalls and monitoring.
- Data location and rules. Check the destination region against your legal duties before you copy anything. The GDPR, India's DPDP Act and sector rules can restrict where personal data and its backups sit, and some regulated firms must tell their regulator before they outsource to a cloud.
- Both bills at once. During the move you pay for the old and the new. Plan the overlap, track cloud spend from day one, size servers from measured use rather than from the old hardware and switch the old ones off promptly.
Words used on this page
Services in this pattern that have changed
Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.
- AWS Closed to new customers AWS Snowball Edge has been available only to existing customers since 7 November 2025. AWS points to AWS DataSync for online transfers and the Data Transfer Terminal for physical transfers. Details
- AWS Closed to new customers AWS Migration Hub and AWS Application Discovery Service closed to new customers on 7 November 2025. AWS points to AWS Transform. Details
- AWS Direction changed AWS stopped reselling VMware Cloud on AWS on 30 April 2024; it continues through Broadcom. Amazon Elastic VMware Service (Amazon EVS) is the AWS-native option. Details
- AWS Closed to new customers AWS Migration Hub Refactor Spaces has been closed to new customers since 7 November 2025. AWS points to AWS Transform for similar capabilities. Details
Sources and further reading
Check details such as features, limits, prices and regions in the providers' own documentation.
- AWS documentation (opens in a new tab)
- Microsoft Azure documentation (opens in a new tab)
- Google Cloud documentation (opens in a new tab)
Announcements about the changed services above
Frequently asked questions
What is lift and shift in cloud migration?
Lift and shift moves an application to the cloud largely as it is, usually from physical or virtual servers to cloud virtual machines. It is the fastest path and the lowest risk, but it brings old design and costs along, so savings often need tuning afterwards.
What are the six common cloud migration strategies?
The most-cited set is rehost (move as is), replatform (small changes), refactor (rebuild for the cloud), repurchase (switch to a software service), retire (switch off) and retain (leave in place for now). Choose one for each application, not one for the whole estate.
How long does a cloud migration take?
A simple application can move in weeks, while a full data centre often takes six months to several years. Time depends on how well you know your estate, how many dependencies exist, how much data there is and how much you change on the way. Waves keep progress visible.
How do you migrate a database with little downtime?
Copy the data once, then stream the changes continuously from the old database to the new one. When they match, stop writes briefly, apply the last changes, switch the application to the new database and keep the old one available for a quick return.
Should I migrate everything to the cloud?
Not necessarily. Some systems cost less or work better elsewhere, because of old hardware, strict latency or location rules, or a licence that does not allow it. Assess each application, retire what nobody uses, and keep the rest where it makes sense.
Want this reviewed for your case?
CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.
Building something else?
Describe it in plain words and get matching services on all three clouds.
Service suggester → Cloud consulting →