The short answer
Treat a migration as small, reversible moves: list every application and dependency, choose a path for each, confirm where data lives and who secures it, estimate running costs, then migrate in waves with a tested rollback. Bad migrations usually skip the inventory or the rollback, not the technology. This applies to AWS, Microsoft Azure or Google Cloud, from a server room or a hosting provider.
1. Know what you have
You cannot migrate what you have not found. Inventory:
- Every server, application and database, even ones "only accounting uses"
- Dependencies: databases, file shares, license servers
- Outside integrations: banks, suppliers, payroll, e-commerce
- Scheduled jobs, scripts and overnight reports
- Business and technical owner of each system
- Licensing terms that restrict cloud use
2. Decide the path for each application
AWS describes seven migration strategies, the 7 Rs; the thinking applies on any cloud.
| Strategy | In plain terms |
|---|---|
| Retire | Switch it off |
| Retain | Leave it where it is for now |
| Rehost | Move it as it is ("lift and shift") |
| Relocate | Move a whole platform, such as virtual machines, to its cloud equivalent |
| Repurchase | Replace it with a software-as-a-service product |
| Replatform | Move it with some changes, such as a managed database |
| Refactor | Redesign it to use cloud services fully |
When each strategy fits
- Retire: nobody uses it, or another system already does the job.
- Retain: it depends on local hardware, was just upgraded, or is not ready.
- Rehost: you need to exit a data center quickly and optimize later.
- Relocate: you run a virtualization platform with a cloud-hosted version.
- Repurchase: a good SaaS product now does what the old system did.
- Replatform: a few changes bring real savings or less maintenance.
- Refactor: the application limits the business and is worth rebuilding.
AWS calls refactoring during a large migration the most complex option and generally recommends moving first, modernizing after. We agree for most organizations (modernizing legacy applications covers what comes next).
3. Settle data residency and privacy
All three major platforms have US regions: AWS lists US East (N. Virginia and Ohio) and US West (Oregon), Azure offers East US, Central US and South Central US (Texas), and Google Cloud has us-central1 (Iowa), us-east4 (N. Virginia) and us-south1 (Dallas). A US region supports data residency but does not by itself keep every copy of your data in the country. Check:
- which services, backups and disaster recovery copies stay in the US;
- whether support, monitoring, email delivery or other add-ons process data elsewhere;
- data-location terms from customers, funders or regulators (government work can require FedRAMP or StateRAMP, CJIS, or CMMC for defense contractors);
- your obligations: sector laws (HIPAA, GLBA, FERPA), the FTC Act, and privacy and breach notification laws of the states where your customers live. Start with the FTC's privacy and security guidance; service-provider contracts, and business associate agreements (BAAs) for health data, usually apply.
This is general information, not legal advice.
4. Agree who secures what
Cloud security is a shared responsibility: the provider secures the infrastructure; you keep identities, data, configuration and, depending on the service, operating systems and applications. The NIST Cybersecurity Framework treats outside providers' risks, cloud included, as your own governance: you stay accountable for what you run on another's platform. Before the first move, set up:
- Single sign-on with MFA
- Least-privilege admin roles
- Separate production and test environments
- Central logging
- Alerts on suspicious activity
5. Estimate and control cost
Costs once hidden in a server purchase become monthly charges. Estimate storage, compute, data transfer, backup and licensing as estimates in US dollars (USD), compare with today's spend (including hardware refreshes and support), and set budget alerts and tagging from day one. See AWS cost optimization for habits that keep spending in check.
Rather talk it through? We can build your inventory, recommend a path for each application and plan the waves, with rollback at every step. Talk to a Promatics specialist
6. Plan waves, testing and cutover
- WavesLower-risk systems first, to build confidence.
- Success criteriaWhat must work, for whom, and how you will check.
- Real-location testsPerformance from the offices and locations where people work.
- Cutover windowAgreed with the business, with a change freeze.
- Rehearsed rollbackIf you cannot go back, you are not ready to go forward.
- Test restoreBackups confirmed in the new environment.
For backups, see backup and disaster recovery.
7. After the move
Migration day starts operations. Decommission old servers securely, update documentation and runbooks, review costs after the first full month, and schedule a rightsizing and modernization review.
What usually goes wrong
The forgotten dependency
A report or integration that read from the old server breaks.
Lift and shift, then shock
Servers sized for on-premises peak run all month at full cloud cost.
Security "later"
Default settings and shared admin accounts become permanent.
No rollback
A problem appears after cutover, with no clean way back.
The checklist
- Inventory of applications, databases, integrations and scheduled jobs complete.
- Business and technical owner named for each system.
- Migration path (retire, retain, rehost, relocate, repurchase, replatform, refactor) chosen per application.
- Licensing checked for cloud use.
- Region chosen and data residency of backups and add-on services confirmed.
- Privacy obligations and contract requirements reviewed.
- Identity, MFA, admin roles and logging in place before the first move.
- Monthly cost estimate in USD, budget alerts and tagging set up.
- Waves, success criteria and cutover windows agreed with the business.
- Rollback plan written and rehearsed.
- Backups configured and a restore tested in the new environment.
- Old systems decommissioned and documentation updated.
When to bring in help
An internal team can often move one simple, self-contained application with no personal information using the provider's documentation. Bring in help for interdependent systems, personal or regulated data, rollbacks nobody can rehearse, or an environment nobody will own afterwards. Our cloud services and migration team plans and runs migrations and can manage the environment afterwards.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- About the migration strategies, AWS Prescriptive Guidance
- AWS Regions, Amazon Web Services documentation
- Shared Responsibility Model, Amazon Web Services
- NIST Cybersecurity Framework, National Institute of Standards and Technology
- Privacy and security guidance for businesses, Federal Trade Commission
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.