Multi-Brand Cloud Consolidation & Migration

A portfolio of production businesses had accumulated infrastructure the way growing companies do: different hosts, undocumented servers, expiring certificates, nobody quite sure what would happen in a failure. Costs were scattered and rising; risk was concentrated and invisible. We ran a consolidation and migration programme — an audit of every workload, a target architecture on managed cloud with a managed database service, migrations planned around business hours, automated SSL and backups, monitoring with a human on call. Every credential is documented and client-owned.

The challenge

Infrastructure sprawl is not a technical failure; it is the residue of normal growth. Each business was set up at a different time, by a different person, on whatever host made sense that month. Nobody made a bad decision and the aggregate was still a mess. Cost sat across a dozen invoices, so nobody could state the total. Several servers had no documented purpose and shutting them down felt too risky. Backups ranged from automated to absent. And there was no answer to the simplest question in operations: if this machine dies tonight, who does what?

Our approach

We audited before we designed — obvious, and routinely skipped, because auditing is tedious and designing is fun. It covered every workload, its traffic, dependencies, data, owner and real criticality, and hunted for what nobody remembered: orphaned staging environments, forgotten cron jobs, domains under personal accounts, DNS at a registrar nobody had opened in years. The target architecture was chosen for operability rather than elegance. Running your own database server saves a modest amount and costs you patching, replication, backup verification and 3am recovery — for a portfolio without an operations team, a bad trade.

Architecture and key decisions

Isolation is the decision we most often revisit. Separate accounts per business give the cleanest blast-radius separation and the cleanest path to a later sale, at the cost of multiplying the operational surface — a commercial call as much as a technical one, better made in a fractional CTO conversation than a server build.

How we sequenced the work

Audit first, producing an inventory and a written risk register. Then the target architecture with its costs, then the account structure and access model, so everything migrated afterwards landed in properly owned accounts. Migrations ran one workload at a time, least critical first, each with a rehearsal, scheduled window, validation checklist and rollback. Old environments were decommissioned only after an observation period. Documentation was written during the work, not promised afterwards.

What to look for if you're commissioning this

Insist on an audit as a distinct, priced deliverable before any migration is scoped. Anyone quoting a consolidation without inventorying what exists is guessing. Ask about rollback for every migration and whether restores are tested or merely configured. Ask whose name the cloud accounts, domains and DNS zones will be in. Ask for the post-consolidation cost model including the managed-services premium. The recurring failures are big-bang weekend cutovers, lift-and-shift of applications never designed for cloud, and leaving old environments running "just in case", which doubles the spend the project was meant to reduce.

Typical cost and timeline

General ranges for this class of programme, not this client's figures. An audit and target architecture for a small portfolio typically takes two to four weeks. Migration typically runs one to three months for a handful of workloads, longer where legacy applications need modification to run on modern infrastructure — that modification, not the migration, usually extends a schedule. Consolidation often reduces total spend through eliminated duplication. See pricing and cloud integration and infrastructure services.

The outcome

Multiple production businesses now run on consolidated, documented, monitored infrastructure with predictable monthly cost, and failures became routine incidents with playbooks instead of emergencies with guesswork. The cost saving is welcome; the disappearance of unquantified risk matters more.

Frequently asked questions

Will consolidating onto one cloud provider actually save money?

Often, through eliminated duplicate environments, right-sized instances and consolidated commitments — but managed services carry a premium offsetting part of that. The more dependable benefit is visibility: a single billing structure means someone can finally state what infrastructure costs and forecast it. Treat cost reduction as a secondary benefit and risk reduction as the primary case.

How do you migrate production systems without downtime?

Usually with a short scheduled window rather than genuinely zero downtime, which is achievable but disproportionately expensive for most businesses. What makes it uneventful is a full rehearsal on a copy, a validation checklist, a window in real quiet hours, and a tested rollback. Migrations go wrong when there is no way back.

Should each business in a portfolio have its own cloud account?

It depends how likely they are to be sold or separated. Separate accounts give the cleanest blast-radius isolation and divestment path, at the cost of multiplied operational overhead. Logical separation within a coherent account structure is usually the better balance for a small team operating several businesses that will stay together.

What should the audit actually produce?

A complete inventory of workloads, hosts, domains, certificates and accounts; who owns and pays for each; the dependencies between them; and a written risk register ranking what would hurt most if it failed. It should name the surprises explicitly — the orphaned server, the domain in a personal email — because those derail migrations when they surface mid-cutover.

If nobody can tell you what your infrastructure costs or what happens when it fails, book a free 30-minute technical session via contact us. For the ongoing side, see managed IT services.