Cloud migration planned workload by workload, with a rehearsed rollback

We combine automated discovery with conversations, because neither finds everything on its own. Network flow data and connection logs show which servers talk to each other and on which ports. We then read configuration files, crontabs, DNS zones, firewall rules and certificate stores for hard-coded addresses, scheduled jobs and expiring certificates. Interviews with system owners add what no tool sees, such as a monthly export the finance team relies on. The result is a dependency map that decides which systems move together.

We start with workloads that are low risk but representative, so the first wave proves the tooling, runbook and monitoring without endangering critical services. During assessment each application is scored on business criticality, complexity, dependencies and the effort its migration path needs. Tightly coupled systems move together in the same wave. Systems already due for retirement are often left out entirely, which reduces both scope and cost.

For most applications downtime can be reduced to a short planned window, and for some it can be close to none. The main driver is data. If a database can be replicated continuously to the cloud, the final switch needs only a brief write freeze while the last changes sync and DNS updates. Systems that cannot replicate need a longer window, which we measure during rehearsals and agree with you in advance.

We copy the bulk of the data first, keep source and target in sync with replication until cutover, and verify the result before switching traffic. Depending on the engine, that means native replication for PostgreSQL or MySQL, or the cloud provider's own migration service. Verification includes row counts, checksums on key tables and application checks such as matching order totals. The source database stays intact until you sign off.

Cost depends on scope: the number of workloads, the path chosen for each, data volumes, downtime constraints and how much refactoring is worthwhile. We run discovery first, then give a fixed quote for the migration work alongside an estimate of your monthly cloud running costs. Seeing both figures together lets you judge the move properly, because a one-off project cost and an ongoing bill affect the business in different ways.

It can be, if servers are copied across at their current size and left running around the clock, so we compare like for like before you commit. The estimate includes costs that are often missed, such as data transfer out, snapshots, NAT gateways and support plans, alongside what you stop paying for, such as hardware refreshes and hosting contracts. Workloads are sized from measured utilisation, and after cutover we check real bills against the estimate and right-size.

Timelines typically depend on the number of workloads, how well they are documented, the volume of data and how much downtime each system can tolerate. Moving one application and its database is a far smaller project than leaving a data centre with dozens of interdependent systems. After discovery we give you a wave plan showing sequence and dependencies, and you review working environments every one to two weeks as each wave progresses.

We run the application in the new environment against a recent copy of production data and test it the way users and other systems will, before any real traffic moves. That covers functional checks, third-party integrations whose IP allowlists may need updating, scheduled jobs, outgoing email, backups with a test restore, and load tests sized to your busiest periods. Monitoring and alerts go live first, so the same dashboards are watched during rehearsal and cutover.

Yes, cloud-to-cloud migrations follow the same assessment, data and cutover discipline as a move from physical servers. The differences lie in mapping managed services such as databases, queues, object storage and identity to their equivalents on the new platform, and in planning for data egress charges. Where the source infrastructure was never written as code, we define the target in Terraform so the new environment is documented from the start.

We roll back to the original environment, which stays running and unchanged until the new one has been accepted. Every cutover runbook defines the go and no-go checks, who makes the call, and the exact steps to reverse the switch, including DNS and any data written during the window. We rehearse the cutover beforehand, so the real event repeats something the team has already done at least once.

No, most applications can move with little or no code change, and a rewrite is rarely the right first step. Rehosting or light replatforming gets you off ageing infrastructure sooner. We recommend code changes only where they clearly pay back, for example storing uploads in object storage instead of on local disk, or moving session state out of memory so the application can run on more than one instance.

Switch them off only after the new environment has run through a full business cycle and nothing still points at the old one. In practice that means month-end, payroll or peak trading has passed cleanly, cloud backups have been restored in a test, and logs on the old servers show no remaining traffic from users, partners or scheduled jobs. We then take a final archive copy, remove old DNS records and firewall rules, and decommission only with your sign-off.

Handover gives your team what it needs to run the new environment without depending on us. The cloud accounts, credentials, Terraform code and pipelines already belong to your organisation. We add a migration record showing where every workload, database and DNS name now lives, runbooks for deployments, backups, restores and common incidents, and walkthroughs on the live system. If you prefer, we continue with support covering monitoring, patching, cost reviews and further waves under an agreed scope.