Infrastructure sprawl in a growing services business is rarely a decision. It accumulates.
A product launches on the hosting that was convenient. A second product launches somewhere else because a different person set it up. A marketing site goes on a third platform. Email lands wherever the domain was registered. Each choice was reasonable in isolation, and collectively they produce an estate that nobody can describe from memory.
This post is about consolidating that, and specifically about the order of operations — because the sequence is what determines whether a migration is boring or eventful.
Start with an inventory you actually trust
Before any architecture, write down what exists. Not what should exist.
For each application: where it runs, what it depends on, who uses it, what data it holds, what happens if it is down for an hour, and whether anyone has ever restored it from backup.
That last column is usually the interesting one. In most estates of this kind, a meaningful number of applications have backups that have never been tested, which means they have backups in the same sense that an untested fire alarm is a fire alarm.
The inventory is also where you discover the dependencies nobody documented — the cron job on one server that populates a table another application reads.
Classify before you design
Not everything deserves the same treatment, and pretending otherwise is how migrations become enormous.
A rough classification that has held up for us:
Business-critical. Customer-facing, holds customer data, revenue stops if it stops. These need managed databases, real backup and recovery, monitoring, and a tested restore procedure.
Operationally important. Internal tools, admin dashboards. An outage is disruptive but recoverable. Standard hosting, backed up, monitored.
Static or archival. Marketing sites, documentation, old projects nobody has touched. These want to be the cheapest, simplest thing available — often just object storage behind a CDN.
Most sprawl is in the third category consuming resources appropriate to the first. Sorting that out is the fastest cost win, and it carries almost no risk.
Separate environments before you migrate anything
If development, staging and production share infrastructure — or worse, if there is no staging — fix that first, on the current hosting if necessary.
The reason is practical. You cannot rehearse a migration without somewhere to rehearse it. A migration executed directly against production is not a migration; it is a live experiment with customers in it.
Environment separation is also the point at which a lot of latent problems surface: hardcoded credentials, configuration that only exists on one server, a dependency on a file that was uploaded manually two years ago. Better to find those in a staging build than during a cutover.
Sequence: data last
The order that has worked for us:
- Static assets and marketing sites. Lowest risk, immediate benefit, and it exercises the new setup — DNS, certificates, CDN, deployment — with nothing important at stake.
- Internal tools. Real applications, real users, but the users are colleagues who can tolerate a problem and report it clearly.
- Stateless application tiers. Move the compute while the database stays put. This is reversible: if it goes wrong, point traffic back.
- Databases. Last, because it is the least reversible step and the one where data loss is possible.
- Email and communications. Deliberately separate, because email carries reputation state — sending domains, warm-up, deliverability — that does not transfer instantly.
The principle behind the order is that each step should be reversible until the one that cannot be.
Backups and recovery are the point, not a phase
It is easy to treat backup as something configured after the migration. It should be the reason for it.
What needs to be true when you are done:
- Backups are automatic and encrypted, with keys managed separately from the data.
- Retention is defined per data class, and long enough to survive a problem discovered late.
- Restores have been performed. Not configured. Performed, timed, and documented.
- Someone other than the person who built it can execute a restore from the runbook.
The last point is the one that gets skipped, and it is the one that matters at 3am.
Plan for the boring disaster
Disaster recovery planning gravitates toward the dramatic scenario. The realistic one is smaller and far more likely: a bad deploy corrupts data, or someone runs a delete against the wrong environment.
Write down, for that case: how it gets noticed, how long that takes, who decides to restore, how much data is lost, and what customers are told. If those answers do not exist in writing, there is a diagram, not a plan.
Where this sits at Dorsko
Dorsko is preparing exactly this consolidation, and the AWS roadmap on our technology page is the target architecture rather than a description of current infrastructure. Nothing on that list is in production on AWS today, and every service on it is labelled with its roadmap state.
The drivers are the ones described above and set out on that page: bringing 10–20 web applications onto one secure foundation, supporting a large number of managed business mailboxes, storing corporate documents securely, separating environments properly, taking daily encrypted backups, establishing disaster recovery, and creating room to run AI-assisted document processing experiments without touching production data.
We have been careful to keep the roadmap and the running estate visibly separate on this site. A plan presented as infrastructure is the same category of error as a roadmap presented as a product.