Cloud Services

No. Some systems are cheaper and safer where they are, particularly older applications with licences tied to hardware and anything with a hard local dependency. The useful output of this work is a list that says what moves, what stays, what gets replaced and what gets retired, with the reason and the cost for each. A migration that assumes everything should move ends up with a data centre bill in a different currency.

It is planned so that it is not, and so that any step can be undone. Systems move in stages, each with a rehearsal, a defined cutover window and a rollback that has been tested rather than described. The stage nobody rehearses is the stage that overruns.

Usually because the environment was moved as it was rather than sized for what it does, and because nothing gets switched off. The recurring causes are machines provisioned for peak running at idle, storage nobody owns, environments created for a test that ended a year ago, and data moving between regions. All of them are findable, and the fix is ownership and alerting rather than a one-off clean-up.

To a degree, and that is a trade to make deliberately. Using a provider’s managed services is cheaper to run and harder to leave; keeping everything portable costs more to operate and buys an option you may never exercise. We make that choice explicit per system rather than adopting a slogan about it in either direction.

Data going in is free, data coming out is charged by the gigabyte, and that asymmetry quietly shapes architecture. The surprising bills come from a short list of repeat causes: backups written to a different provider, an analytics tool pulling a full copy of the database out every night, media served straight from storage instead of through a cache, and services chattering across regions because the application landed in one and the database in another. None of it is exotic and all of it is measurable before you commit to anything. We estimate egress from a month of your real traffic during the assessment rather than from an architecture diagram, and where the figure is significant we design around it, with caching and by keeping talkative components in the same place.

It is a reasonable decision and a poor accident. Deliberate versions exist: a workload that has to sit close to a customer's own systems, a regulator who wants failure isolated, a product genuinely sold through more than one marketplace. What we usually find instead is that one team chose one provider, an acquisition brought another, and you now pay for two sets of skills, two billing models, two security configurations and the connectivity between them, without anyone having made that choice. The real cost is attention rather than the second account. If the second provider exists for a reason you can state in one sentence, keep it and run it properly. If you cannot state the reason, consolidating is often the cheapest improvement available in the first year.

Beyond the licensing traps, four categories come up again and again. Anything with a physical dependency: machinery, cameras, a production line, a laboratory instrument that expects a server on the same network as itself. Steady workloads that run flat at high utilisation all year, where owned hardware is often still cheaper because the cloud's advantage is paying for variation and there is none. Systems whose vendor will only support a configuration they certify, which is common in older finance and clinical software and is worth a phone call before any planning starts. And data with a residency requirement your chosen region does not satisfy. Each can be worked around at a price, and the assessment exists to put a number against that workaround rather than assume it away.

Somebody has to own it, and how much of a person that is depends on what you chose. Managed services from the provider push more of the operating work onto their side and less onto yours, at a higher unit price. Running your own virtual machines is cheaper per hour and hands you patching, sizing and capacity planning, which is a real job with a real salary attached. The parts needing an owner regardless are access and permissions, the monthly bill, and knowing which environments exist and why. Most mid sized companies settle on a split: one internal person who owns the accounts and the spend, with us for the depth and the busy weeks. What does not work is assuming the migration ends the effort. The invoice is monthly, so the attention has to be too.