Cloud Migration

What Has To Exist Before the First Workload Moves

Before any application can land, there is a foundation nobody asks for and that never appears in a workload inventory: an account structure, a network path, name resolution, an identity decision, and somewhere for logs to go. The first migration wave either builds that deliberately or improvises it under time pressure. It is built once and reused by everything that follows, which is why the first workload looks disproportionately expensive and the fifth does not, and why judging the whole program by the cost of wave one is misleading.

Addressing is the piece that is expensive to change later. On-premises networks were laid out years ago inside RFC 1918 space, and that space is small enough that an existing corporate range and a default cloud range collide regularly. If the two overlap, routing between them cannot be fixed at the routing layer; you get network address translation on the path, or you renumber one side. Every workload placed into the plan makes changing it harder, so the address plan is decided before anything moves, not after the third application is running.

Resolution and identity are the two that drag. Name resolution has to work in both directions: migrated systems still need to resolve internal names left behind, and on-premises clients need to resolve the new ones. Identity is a per-application question rather than one program-wide choice, and each application either keeps authenticating against a directory that has been extended into the cloud network, or is changed to federate with a cloud identity provider. Beyond addressing and identity, the items below are the ones that get deferred and then block a cutover date.

• An account, subscription, or project structure with a tagging scheme that matches how you will want the bill broken down later, because retrofitting tags onto running resources is manual work nobody schedules
• Connectivity sized for the migration transfer rather than for steady state: IPsec over the internet is capped per tunnel in the low gigabits per second, tunnels do not aggregate by default, and a dedicated circuit is provisioned in weeks, not hours
• Conditional forwarding, or the provider equivalent, configured on the DNS servers on both sides before the first system needs it rather than during the cutover window
• A destination for logs and metrics chosen and actually receiving data before anything production-facing lands, so the first workload is observable from the moment it starts
• A defined non-production area, so cutover rehearsals do not run in the same account as the systems they are rehearsing for

The Database Usually Decides How Long the Outage Is

For most business applications the application tier can be built in advance and left idle at no risk. Data cannot. The cutover window is not the time it takes to start servers on the new side; it is the time to get the last consistent copy of the data across, load it, rebuild indexes, and verify it. Estimating that from database size alone is where plans go wrong, because the number is set by the narrowest point in the chain, whether that is the link, the read rate on a source that is still serving users, the write rate on the target, or the index build that only starts once the load finishes.

The standard way to shrink it is to seed and then follow. Take a bulk copy while the source stays live, then run continuous replication from the change log, so the target keeps pace with ongoing writes. Cutover then reduces to stopping writes at the source, waiting for lag to reach zero, and repointing the application. This depends on two things being true: the source has to expose a usable change stream, and every replicated table needs a stable way to identify a row. Tables without a primary key are a common reason a replication-based plan quietly reverts to a long copy window.

Two cases break the pattern. Changing database engines is not replication with extra steps; it is a conversion of types, collation behavior, and any logic that lives in stored procedures, and the testing dominates the schedule rather than the copying. The second is rollback. Once the new database has accepted writes, going back means replicating in the reverse direction, which few plans build and fewer test. If reverse replication is not in place, the rollback window closes at the first write on the new side, and that belongs on the plan as a stated limit rather than being discovered during the window.

Validating a Data Migration Beyond Record Counts

Reconciling counts and totals proves the rows arrived. It does not prove the values survived intact, because the failures that get past counting are the ones that change meaning without changing cardinality: a character set that substitutes on the way in, a time zone that shifts every timestamp by hours, a generator that restarts at one. These are worth checking explicitly the first time you move a given engine and schema, since each check below costs far less than finding the same problem after a month of new writes has been layered on top of it.

• Content checksums on the tables carrying money, identity, or regulatory records: hash a canonical serialization of each row's columns on both sides and compare, so an altered value is visible where a matching count is not
• Character set and collation on the target verified against the source, because a different collation changes sort order and can change what a unique index treats as a duplicate, and in MySQL the older three-byte utf8 will not store four-byte characters that utf8mb4 accepts
• Time zone handling: whether the column type carries an offset at all, what the server and session time zones are on each side, and whether the application had been relying on the old server's local clock
• Sequence, identity, and auto-increment generators advanced past the highest migrated key, since a bulk load inserts explicit values without moving the generator and the first insert after cutover collides
• Constraints, triggers, and foreign keys that were disabled to make the load fast, confirmed re-enabled and validated against existing data rather than simply re-declared as trusted
• Connection encryption and client driver versions on the new path, because managed endpoints commonly require TLS where the local server did not, which surfaces as a client library and certificate trust problem rather than a database problem

What the Migration Needs From Your Side

Access is usually the critical path. Read access to source systems, credentials or delegated accounts in the target, someone who can approve a firewall or network change without waiting a full change board cycle, and a named contact per application who can say what working means for that system. Access requests routed through approval queues can take longer than the technical work they unblock, and almost all of them can be started before assessment finishes.

Then there are decisions that are not ours to make. Acceptance criteria per system, stated as something checkable rather than as user satisfaction. Maintenance windows and freeze periods, including the ones set by finance and by contractual obligations rather than by IT. And who holds authority to call a rollback mid-cutover without convening a meeting, which should be one named person who is reachable, agreed before the window opens rather than negotiated inside it.

The dependency that gets underestimated is that part of the connection inventory cannot be discovered from your systems at all. Which partner holds your outbound addresses on file, who consumes an export, which auditor expects a file on a fixed date each month: that knowledge lives with people and in contracts, not in a configuration you can read. Collecting it takes calendar time and someone with the standing to ask across departments, so it runs in parallel with technical assessment rather than after it.

When Migration Is Not the Service You Need

Some estates do not have a migration in them. If the applications in scope are already vendor-hosted software as a service, there is nothing to move: the work is identity consolidation, integration between the tenants, and confirming your data export rights, which is a different engagement. If the driver is that one report is slow or one nightly batch does not finish in its window, moving the estate to rent faster hardware is an expensive substitute for profiling the query, and the problem usually follows the workload onto the new platform.

There is a narrower version of the same point. Where an application is already funded and scheduled for a ground-up rewrite, and nothing outside your control is forcing a date, meaning no lease ending, no hardware leaving support, and no externally fixed deadline, the target platform belongs in the new design rather than in a move the rewrite will discard. This is a different case from the re-platforming that should be funded alongside a rehost: re-platforming keeps the application and changes what it runs on, so a rehost is a step toward it, while a rewrite replaces the application outright. When one of those external constraints does apply, the constraint decides and moving first is still the right call.

Physical coupling is the clearest case of a system that should stay where it is. A server wired to equipment on a floor, a license enforced by a hardware key on a specific host, an instrument writing to a share over a local link: the application can move, but the thing it talks to cannot. What was a sub-millisecond call across a local switch becomes a round trip measured in tens of milliseconds over a link that also has its own maintenance schedule. Chatty designs that make hundreds of calls per transaction are where this shows up first, because added latency multiplies by call count rather than being absorbed once.