Most migrations we get called into have already started. Someone spun up an EC2 instance eighteen months ago, then another, then an RDS database, and now half the company runs on AWS without anyone having drawn a diagram. The other half still sits in a rack in a Noida data centre that nobody wants to touch.
That is the normal starting position, and it is fine. What is not fine is treating the move as a weekend job. Here is the sequence we run, and roughly what each step costs you in time.
Step one: find out what you actually have
Discovery is boring and everyone wants to skip it. Do not. You need an inventory of servers, databases, scheduled jobs, licence keys, SSL certificates, DNS records, and — the one that bites hardest — the undocumented dependency on a machine somebody set up in 2019 and left running.
AWS Application Discovery Service can agent-scan your existing estate, but a spreadsheet built from interviews works too when the estate is small. What matters is the dependency map: which service calls which, and what breaks when a hostname changes.
- Compute — every VM or bare-metal box, with CPU, RAM, and actual observed utilisation, not the spec sheet
- Data — database engines and versions, total size, and how much daily change there is (this drives your cutover window)
- Integrations — payment gateways, SMS providers, anything with an IP allowlist that will need updating
- Licences — Windows Server, SQL Server, and anything with per-socket pricing that changes when you move
Step two: pick a strategy per workload, not per company
AWS documents seven migration strategies — the 7 Rs. You do not apply one to everything. A typical Indian SMB estate ends up split across three or four of them.
- Rehost (lift and shift) — fastest, lowest risk, and where most legacy applications should go first. AWS Application Migration Service replicates the running server block by block and cuts over in minutes.
- Replatform — same application, better managed service underneath. Self-managed MySQL becomes Amazon RDS. You stop patching database servers forever. This is usually the highest value-per-hour change available.
- Repurchase — the self-hosted CRM nobody has upgraded since 2021 becomes a SaaS subscription. Cheaper than migrating it.
- Refactor — rewrite for cloud-native. Real value, real cost. Do it after the migration, on the one or two services where it pays.
- Retire — you will find servers doing nothing. In every estate. Switch them off before you pay to move them.
- Retain — some things stay put, usually for compliance or a licence you cannot move yet. That is a valid answer.
Step three: build the landing zone before you move anything
The account structure you set up in week one is the one you live with for years. Getting it wrong is expensive to undo, because IAM policies, VPC CIDR ranges, and billing all hang off it.
At minimum: separate AWS accounts for production and non-production under AWS Organizations, service control policies stopping anyone from disabling CloudTrail or launching in regions you do not use, IAM Identity Center for human access with no long-lived access keys, and a VPC CIDR range that does not overlap with your office network or anything you might acquire later.
AWS Control Tower will set most of this up. It is worth the afternoon.
Step four: cutover, rehearsed
Replication runs for days or weeks in the background while both environments stay live. The cutover itself is short — you stop writes to the old system, let replication catch up, flip DNS, and verify.
Rehearse it at least once on a non-production copy, with a stopwatch and the same people who will be awake on the night. Write the rollback step down before you need it. Cutovers do not usually fail because the technology failed; they fail because a TTL was set to 24 hours and nobody noticed.
A note on DNS. Drop your TTLs to 60 seconds at least 48 hours before cutover. This one line has saved more migrations than any tool.
Step five: the part everyone skips
You are on AWS. The bill arrives. It is higher than the quote, because lift-and-shift means you moved your over-provisioned servers exactly as they were, and they are now billed hourly instead of sitting in a rack you already paid for.
The month after cutover is when right-sizing, Savings Plans, storage tiering, and deleting the orphaned EBS volumes actually happen. Budget for it as part of the project, not as a surprise. Same with the security baseline — GuardDuty on, Security Hub on, CloudTrail retained, root account locked down with MFA.
How long does it take?
For a small estate — a dozen servers, one or two databases, no exotic licensing — discovery through cutover is usually a matter of weeks rather than months, with the landing zone eating the first chunk of it. Anything with a mainframe, a Windows licensing question, or a database version AWS does not support directly takes considerably longer, and anyone quoting you a fixed timeline before discovery is guessing.