You avoid downtime in a migration by rehearsing the cutover, not by moving faster. Copy the data early, keep it syncing, drop your DNS time-to-live days before the switch, and run the whole cutover once on a Tuesday evening when nobody is watching. The real move then takes twenty minutes and you already know every step, because you have done it.
Pick the strategy before you touch a server
AWS’s enterprise strategy team published the framework most of the industry still borrows, the six Rs: rehosting (lift and shift), replatforming (lift, tinker and shift), repurchasing (move to a SaaS product instead), refactoring, retiring and retaining. The value of the list is that two of the options involve no migration at all. Every estate we assess has at least one server running something nobody uses.
| Strategy | What you do | Effort | Cutover risk | Pick it when |
|---|---|---|---|---|
| Retire | Switch it off after checking who uses it | Lowest | None | Usage logs are empty and the owner has left |
| Retain | Leave it where it is for now | None | None | Hardware is paid for, or a licence or regulator pins it down |
| Repurchase | Replace with a SaaS product | Medium | Low | The system is generic: email, CRM, payroll, helpdesk |
| Rehost | Move the VM as-is | Low | Medium | You need out of a data centre on a deadline |
| Replatform | Move, but swap in a managed database or runtime | Medium | Medium | You want fewer things to patch afterwards |
| Refactor | Rebuild for cloud-native services | Highest | Highest | The application is strategic and is actively developed |
Microsoft’s Cloud Adoption Framework splits the same journey into phases: strategy, plan, ready, migrate, modernise. The phase that gets skipped is always ready, which is where you build the landing zone: accounts, identity, networking, logging and guardrails. Skipping it feels fast for three weeks and then costs you a rebuild.
- Recovery point objective: how many minutes of data you can afford to lose.
- Recovery time objective: how long you can be down before it hurts.
- The size of the dataset in GB, measured not guessed.
- The maintenance window you can actually get signed off.
- The rollback deadline: the time at which you stop and go back.
What moving the data actually costs
Ingress is free on every major platform. Egress is where the money is, and it matters twice: once if you are leaving an existing cloud, and once for the ongoing traffic your new deployment serves. Azure’s bandwidth pricing page lists the first 100 GB a month free from North America and Europe, then $0.087 per GB for the next 10 TB, falling to $0.083, $0.07 and $0.05 per GB as volume rises. AWS’s own S3 pricing examples use $0.09 per GB from Ireland to the internet, and AWS provides 100 GB a month free from its regions.
If you are moving off an existing cloud, the exit is cheaper than it used to be. AWS announced in March 2024 that it waives data transfer out to the internet for customers moving off the platform, applied through a support request, and Google Cloud published an equivalent programme for customers migrating away. The European Commission’s Data Act, in application since 12 September 2025, is the regulation behind much of that movement: it sets out switching obligations for cloud providers operating in the EU.
| Scenario | Volume | Published rate | Rough one-off cost |
|---|---|---|---|
| Lifting 2 TB of files into a new cloud | 2,048 GB | Ingress is free | $0 |
| Pulling 2 TB back out to the internet later | 2,048 GB | $0.087 per GB (Azure, first tier) | About $169 |
| Copying 2 TB between two regions of one provider | 2,048 GB | $0.02 per GB (AWS Oregon to N. Virginia) | About $41 |
| Exiting a provider entirely | Any | Waived by AWS and Google Cloud on request | $0, with paperwork |
Where downtime really comes from
In ten years of doing this, unplanned downtime almost never comes from the cloud platform. It comes from the same short list, every time.
- DNS caching. A record with a 24-hour TTL means some users keep hitting the old server all day. Drop the TTL to 300 seconds at least 48 hours before cutover.
- Data drift. The copy you took on Friday is stale by Monday. Either freeze writes during the window or run continuous replication and cut over on a short pause.
- Licence keys bound to hardware. Some older software checks a MAC address or CPU serial. Find out before cutover night, not during it.
- Hard-coded IP addresses. Firewall allowlists at partners and payment providers, print servers, scheduled jobs. Grep the codebase and ask every integrator.
- Outbound mail. New IP addresses have no sending reputation, and SPF records rarely include them. Expect bounced invoices unless you plan this.
- Scheduled jobs running twice. If the old and new systems both run the nightly billing job, you will find out in the morning.
If your rollback plan is a sentence rather than a tested procedure, you do not have one.
A four-week plan that keeps the lights on
This shape works for a single application with a database, which covers most first migrations. Bigger estates are the same four weeks repeated per wave.
- Week one: inventory and landing zone. List servers, services, integrations, certificates, scheduled jobs and who owns each. Build accounts, identity, networking, logging and backup policy in the destination.
- Week two: build and first copy. Stand up the target, restore a full copy of the data, start replication. Point a staging hostname at it and let your team use it.
- Week three: rehearsal. Run the full cutover on the staging copy, timed, with the runbook open. Then run the rollback. Record how long each step took, because everyone underestimates verification.
- Week four: cutover and watch. Execute, verify, keep the old system intact and read-only for two weeks. Do not decommission anything in the first fortnight.
Two weeks of parallel running costs you a fortnight of duplicate hosting. That is the cheapest insurance in the project, and it is the difference between a bad evening and a bad quarter.
Cutover day, step by step
Hand this to whoever is awake. Times are indicative for a small application with a database of a few hundred gigabytes.
| Step | Action | Typical time | Go or no-go |
|---|---|---|---|
| T-48h | DNS TTL lowered to 300 seconds; stakeholders told the window | 15 min | Abort if TTL change is not propagating |
| T-2h | Final replication check; backup of source taken and verified | 30 min | No-go if the restore test fails |
| T-0 | Writes paused on the source; final delta synced | 10-20 min | No-go if the delta does not converge |
| T+20m | Application started in the new environment; smoke tests run | 20 min | Roll back if a critical test fails |
| T+40m | DNS switched; mail, payments and integrations verified | 20 min | Roll back if payments or mail fail |
| T+2h | Monitoring confirmed; writes re-enabled; team told it is live | 15 min | Decision point for rollback deadline |
| T+14d | Old environment decommissioned after a final backup | 1 hour | Point of no return |
The month-two bill is part of the project
A migration is not finished when traffic moves. It is finished when the bill makes sense. Fresh migrations are oversized by design, because you sized the cloud instance to match the old server rather than the actual load. Flexera’s 2026 State of the Cloud research puts estimated wasted IaaS and PaaS spend at 29%, and reports 71% of organisations now run a cloud centre of excellence to keep it in check.
- Wait two to four weeks, then look at real CPU, memory and IOPS percentiles.
- Resize down one step at a time. Most rehosted servers are one or two sizes too big.
- Move cold data to an archive tier and delete snapshots nobody has a policy for.
- Only then buy commitment discounts. AWS Savings Plans and Reserved Instances reach up to 72% off on-demand, but committing to the wrong size locks in your mistake for a year.
That sequence matters: rightsize first, commit second. Our deeper guide on cutting cloud costs without losing performance covers the levers in order of payback. Before you choose a destination, it is worth reading our take on AWS, Azure and Huawei Cloud, and once you are live, backup and recovery is the first thing to get right. We run migrations remotely for clients worldwide as part of our cloud solutions work; if you need an engineer physically on site in Sri Lanka, that is eudora.lk.
Frequently asked questions
How much downtime does a migration actually need?
For a small application with continuous replication in place, a 20 to 60 minute pause on writes is realistic, and some setups manage near-zero with a read-only window. The number that matters is not the theoretical minimum, it is the time your rehearsal took. Use that, add 50%, and book the window.
Can we migrate without a maintenance window at all?
Sometimes, with database replication, dual writes or a read-only period rather than a full stop. It costs more engineering time and more rehearsal. For most businesses a 30-minute window at 7am on a Sunday is cheaper and less risky than building a zero-downtime path.
What does it cost to move data into the cloud?
Nothing, in transfer terms: every major provider makes ingress free. The costs are the engineering time, the temporary double-running of two environments, and later the egress if you move data back out. Azure publishes $0.087 per GB for the first chargeable tier from North America or Europe, and AWS uses $0.09 per GB in its own pricing examples.
Are we locked in once we migrate?
Less than you would think on infrastructure, more than you would like on managed services. AWS and Google Cloud both waive internet egress for customers leaving, and the EU Data Act has applied since September 2025. The real lock-in is proprietary services and team skills, so keep your data exportable and your deployment scripted.
Do you migrate systems remotely?
Yes. Everything we do for international clients is delivered remotely: planning calls, shared runbooks, work carried out in your own cloud accounts, and a rehearsal you can watch. On-site work in Sri Lanka is handled through eudora.lk.
Planning a move and want the cutover rehearsed properly? Send us your inventory and we will come back with a plan and a window. Get in touch with Eudora Technology to talk about your project.
Sources
- 6 Strategies for Migrating Applications to the Cloud
- Free data transfer out to internet when moving out of AWS
- Data Act: policy overview
- Migrate workloads to Azure (Cloud Adoption Framework)
- Bandwidth pricing (data transfer)
- The new era of cloud: what 2026 data tells us about spend, scale and strategy
.jpg){kind=link}
.JPG){kind=link}