Cloud data migration without surprises: sequence, cost and what stays in-house

A cloud data migration rarely fails because of the technology. It fails because moving started before anyone knew what was there, because nobody decided what "done" meant, or because the monthly bill, which didn't exist with your own server, shows up in month three and nobody had budgeted for it. The move itself is the most predictable part of the project. Everything else is the hard part.

This guide walks through the process in order: what to inventory, which strategy fits each system, how to sequence the phases, what it costs to run afterwards and what is better kept out of the cloud. It's written for whoever approves the project or answers for it, not for whoever configures it.

What does migrating data to the cloud mean, and why isn't it just copying files?

Migrating means moving data from an environment you operate (a server in the office, a rented data centre) to infrastructure someone else operates and you access by contract. Simple so far. The confusion comes from assuming the data travels on its own.

In practice four different things move, and each carries its own risk:

• The content: databases, files, backups, history.
• The logic around it: stored procedures, scheduled jobs, scripts someone wrote eight years ago and nobody remembers.
• The access: who gets in, from where, with what permissions. On your own server this is usually implicit in the office network; in the cloud it has to be declared.
• The connections: the ERP that reads from that database, the dashboard that refreshes every night, the spreadsheet someone hooked up through ODBC that holds up a monthly report.

If you move only the content and forget the other three layers, cutover day is when you find out that what breaks is exactly what kept operations running.

What should you inventory before moving anything?

The inventory is the phase most often skipped and the one that saves the most. You don't need an expensive tool: you need a table and two weeks of asking the right people. For each system, note at least:

1. What it holds and who answers for it. An owner with a name and surname, not "IT". 2. How big it is and how fast it grows. Current size and growth rate drive storage cost and the time of the initial load. 3. Who and what queries it. Applications, reports, integrations, users with direct access. This is where hidden dependencies show up. 4. What legal requirements apply. Personal data, health data, information under mandatory retention. This shapes where it's hosted and how it's encrypted. The basics are in GDPR and AI compliance. 5. How long it can be down. The business knows the answer even if IT hasn't written it down: is an hour without invoicing a problem, or is an hour without the dashboard just an annoyance? 6. Whether it's really still in use. Nearly every company finds, at this step, databases nobody has queried in two years.

Migrating dead data costs money every month and widens your risk surface. The inventory is the cheap moment to decide what gets archived, what gets deleted with a backup and what gets migrated.

And one more thing: defective data moves just as defective as before. If you already know there are duplicates or meaningless fields, measure them before the move using the criteria in data quality; afterwards nobody will want to reopen the subject.

Which strategy fits each system?

There's no single way to migrate, and not everything is treated alike. The usual strategies, from least to most effort:

| Strategy | What it means | When it fits | Main risk | |---|---|---|---| | Move as-is | Move the system unchanged, just onto different infrastructure | Stable application, short deadline, little room to touch anything | You inherit every problem and pay for the cloud without using its benefits | | Move with tweaks | Same system, but using managed services (for example, a managed database) | You want to get rid of manual patching and backups | Small incompatibilities that only surface in testing | | Redesign | Rewrite part of the system to take advantage of the new environment | A system that was already a problem and is worth modernising | Long project; scope balloons easily | | Replace | Drop the system and adopt an existing new one | The function is standard and doesn't set the company apart | Migrating data into the new format, which is another project | | Retire | Archive or delete | The system is no longer used | Finding out late that someone needed it once a year |

The usual temptation is to mix the move with modernisation: "since we're moving it anyway, let's rebuild it". It's the surest shortcut to a twelve-month project. Separate the two moves: first transfer with minimal adjustments and stabilise; then, measuring real costs, decide what to redesign.

In what order do the phases go?

The sequence that works best is the one that lowers risk at every step and lets you stop without damage:

1. Inventory and scope decisions. As described above. It ends with a prioritised list and a strategy per system. 2. Cloud foundations. Accounts, networks, permissions, encryption, cost tagging and spending alerts. Done before a single piece of data goes up, because tidying an environment that's already populated is far more expensive. 3. A pilot with something that won't hurt. A small system, preferably internal, that won't stop invoicing if it goes wrong. It fine-tunes the procedure and measures real transfer speeds. 4. Initial load and synchronisation. The bulk of the data is copied and kept in sync with the source while the source keeps running. This is where you find out how long it really takes. 5. Testing with real users. Not just checking that the figures match. Have someone from administration run their month-end close against the new environment and compare. 6. Cutover. An agreed window, with a rollback plan that's written down and tested. Pick a quiet moment, not the last day of the quarter. 7. Coexistence and shutdown. The old system stays read-only for a period defined in advance. Switching off the old server is part of the project: if it stays on "just in case", you've doubled the cost.

The useful question before cutover isn't "will it work?", but "if it doesn't work at ten at night, who decides to roll back and how long does it take?". If nobody can answer, you're not ready.

How much does a cloud migration really cost?

This is where the most frequent surprises live, and almost all share one cause: the move gets budgeted and the life afterwards is forgotten. An honest budget separates three blocks:

• Project cost (one-off): inventory, design, migration work, testing, training. It depends on the number of systems and their complexity, not on volume in terabytes.
• Recurring cost (monthly): storage, compute, backups, network, licences, monitoring. This is the figure management must approve as a new fixed expense.
• Cost of running and governing (ongoing): someone who reviews spending, adjusts resources, applies security changes and handles incidents.

The recurring items least often anticipated:

• Data egress. Moving data in is usually cheap; taking it out, for other systems or to change provider, may not be. Ask in writing before signing.
• Test environments nobody switches off. One created for a pilot and forgotten bills every month.
• Oversized resources. More capacity than needed gets bought "just in case" and the promised saving never arrives.

To avoid surprises, every resource should carry a project and owner tag, and there should be an alert when spending drifts from plan. And always compare against the full cost of your own environment, including electricity, hardware renewal and the hours of whoever keeps watch over it. The cloud isn't always cheaper; sometimes it costs the same, with less risk and more flexibility, and that's a perfectly valid argument if it's put forward honestly. The general logic of how these projects are budgeted is in what an AI project costs, and almost all of it applies here too.

What is better kept in-house?

Not everything has to go, and anyone who tells you otherwise is selling something. There are four situations where keeping a system on-premises is a reasonable decision:

• Legal or contractual location requirements. Some clients and sectors require certain data not to leave a given scope. If the contract says so, you comply.
• Latency with local machinery. A system that controls a production line and responds in milliseconds shouldn't depend on an internet connection.
• Depreciated, stable hardware. A server that works, is paid for and is maintained by someone competent doesn't need to retire just because.
• Very predictable, constant loads. Cloud elasticity is an advantage when demand varies. If the load is flat all year, the economic advantage shrinks.

The usual answer in mid-sized companies is a mixed model: what changes, grows or is queried from outside goes to the cloud; what is stable, sensitive or tied to the physical environment stays. That boundary should be written down and reviewed every year. If you're also deciding where to host the analytical store, the comparison is in data warehouse for mid-sized companies.

How do you know the migration went well?

"It works" isn't a criterion. Define measurable criteria before cutover and review them at thirty days:

• Totals on the key tables match the source (row counts, sums of amounts).
• Critical processes, like the month-end close, finish as fast or faster, and the old system is switched off or archived as planned.
• The month's spend is within the budgeted range, and every euro is assigned to a project.
• A backup restore has been performed at least once in the new environment, to confirm it can be recovered and not merely stored.

A backup that has never been restored is an assumption.

Frequently asked questions

How long does a cloud data migration take?

It depends on the number of systems and their dependencies, not just on volume. An isolated, well-understood database can move in weeks. A set of intertwined systems, with integrations and users everywhere, is measured in quarters. The most underestimated phases are the initial inventory and testing with real users.

Is it safe to keep data in the cloud?

It can be as safe as or safer than your own server, as long as it's configured properly: encryption, least-privilege permissions, access logging and verified backups. Security is a shared responsibility: the provider protects the platform, and you protect your access and your data.

Can you migrate without stopping the business?

In most cases yes, by keeping source and destination in sync until cutover, which shrinks to a short agreed window. What is almost never possible is a cutover with zero interruption across every system. The business should know in advance when that window is and what won't work during it.

If you're weighing a move and aren't sure what systems you have, which depend on which, or how much the monthly bill will add up to, the first step isn't choosing a provider: it's that inventory. It's part of what we do in the audit, with your real systems and no commitment to continue, and if you'd rather talk it through first, let's talk.