Back to the blog
4 min read

The first 30 days of a successful data migration project

Isak La Fleur EngdahlBy Isak La Fleur Engdahl

Most migrations are won or lost before anyone seriously starts moving data. The first 30 days aren't about tooling or load scripts – they're about understanding what actually needs to migrate, who owns it and how good the data really is. Do that work properly and the rest of the project becomes predictable. Skip it and you pay for it at cutover.

Here's how I structure the first month.

Week 1 – Discovery workshops

It all starts with understanding the business, not the system. I bring together the people who actually use and own the data – not just IT – and walk through how the work is done today.

  • Which business processes rely on the data we're migrating?
  • Which systems and registers are involved, and how do they connect?
  • Where are people already working around data that falls short?
  • What does "done" mean – what does a successful go-live look like to them?

The goal of these workshops isn't a requirements document. It's to find the data owners, understand the decisions that have to be made, and capture the tacit knowledge that never appears in any schema. This is also where I start listening for risk: legacy integrations, manual Excel steps, registers that "no one really dares to touch".

Week 2 – Source system analysis

Once I understand the business, I turn to the systems. Source system analysis is about mapping where the data lives and how it hangs together.

  • Which tables and objects hold the data we discussed in the workshops?
  • What do the relationships look like – keys, dependencies, reference data?
  • Are there multiple "truths" about the same thing across systems?
  • What is active data versus history that could just as well be archived?

Here I often sketch a simple conceptual data model (a crow's foot ERD goes a long way) so everyone – business and IT – sees the same picture. A migration is never better than your understanding of the source.

Week 2–3 – Data profiling

This is the step most projects skip, and it's almost always the most expensive mistake. Assumptions about data quality are guesses until you've measured. Profiling replaces opinions with facts.

  • Completeness – how many records are missing values in business-critical fields?
  • Duplicates – how many customers, products or suppliers are there really?
  • Format and consistency – do codes, dates and units line up across systems?
  • Anomalies – free-text fields full of "creative workarounds", invalid combinations, orphaned records.

I profile with Python and SQL and present the results so the business can decide: what do we clean in the source before migration, what do we transform during, and what do we leave behind? At the same time we set quality expectations – acceptance criteria per object – so that "good enough" becomes measurable instead of an opinion.

Week 4 – Defining scope

Now there's a basis for the most important decision in the whole project: what gets migrated – and just as important, what does not?

There's a strong instinct to bring everything along "just in case". But every extra object has to be mapped, cleansed, tested and reconciled. Actively choosing to leave data behind is one of the most time-saving decisions you can make. For every data object, ask: is it needed in the target system, or is an archive enough?

By the end of the month I want a scope the business understands and has signed off on – with clear data owners, known quality issues and a realistic boundary. That's the difference between a plan and a hope.

What you have after 30 days

A well-invested first month gives you:

  • Identified data owners per domain (customer, product, supplier …).
  • A map of the source systems and how the data connects.
  • A fact-based picture of data quality with defined quality expectations.
  • A scoped, signed-off boundary – including what's deliberately left behind.

None of this is glamorous, and it rarely shows up in a project plan. But it's exactly the work that makes go-live uneventful. The migration isn't a transport leg – it's where the transformation succeeds or fails, and the first month lays the foundation.

Facing a migration and want to start on the right foot? Get in touch – I'm happy to share how I work.