What a Data Migration Readiness Assessment Should Cover

The most expensive migration mistake is usually made before delivery starts: signing a large statement of work on hope. Hope that scope is clear. Hope that source quality is “fine.” Hope that cutover will fit a weekend. Hope that the SI’s configuration plan automatically includes data proof.

A data migration readiness assessment exists to replace that hope with evidence. It is a time-boxed piece of discovery that prices risk before you commit the bulk of programme spend: whether you are moving CRM, ERP, finance, SQL estates, or a multi-system landscape.

At Cyber Samurai, the Data Migration Readiness Assessment runs about three weeks and typically sits in the £15,000-£22,000 range. It is stage zero of our migration methodology: clarity before build. This article explains what any serious readiness assessment should cover: so you can judge ours or anyone else’s.

What readiness is (and is not)

Readiness is

• A structured investigation of scope, quality, complexity, constraints, and cutover options
• A scored view of risks that would burn money in delivery
• Costed path options (minimal / recommended / strategic)
• Artefacts an SI or internal team can reuse (so you do not pay for discovery twice)
• A go/no-go and shape recommendation for the delivery programme

Readiness is not

• The full migration build
• A vague workshop series with no evidence pack
• A tool licence recommendation pretending to be discovery
• A rubber stamp for a date already promised to the board without data foundations
• Optional “PMO nicety” on programmes already large enough to hurt if they fail

If a supplier’s “assessment” produces only slides and no risk register, scorecard, or costed options, it is marketing, not readiness.

When you should run one

Strong triggers:

• CRM, ERP, or finance change planned within ~12 months
• Programme budget already heading above ~£150k, or business-critical systems in scope
• M&A data integration on the horizon
• Azure / SQL modernisation tied to operational cutovers
• Source landscape poorly documented, multi-entity, or integration-heavy
• Previous migration attempt failed or stalled
• Board date exists but evidence does not

Running readiness after the SOW is signed still helps, but you lose commercial leverage. Best value is before the big commitment.

What a proper assessment should cover

1) Source estate inventory and dependency map

You cannot migrate what you have not found.

Should include:

• Systems of record and shadow stores (including spreadsheet-critical paths)
• Interfaces and batch jobs that create residual open positions
• Reporting and downstream consumers that will break if identity changes
• Volumes by major entity (measured, not guessed)
• Ownership: who believes they own each domain

Output: landscape diagram + inventory table + “unknowns” list.

2) Scope framing: in, out, and later

Force explicit decisions:

• Objects in scope for go-live vs later waves
• History depth by domain (CRM activities, ERP movements, finance detail)
• Open transactions vs openings-only choices
• Entities, brands, geographies
• Data products: masters, opens, balances, history: separately

Output: draft scope pack the steering group can argue with productively.

3) Data quality profiling (evidence, not anecdotes)

Profile what will actually break mapping and reconciliation:

• Nulls on mandatory business keys
• Orphans and broken relationships
• Duplicates on customers, items, suppliers
• Referential integrity hotspots
• Code-set sprawl (statuses, UOMs, country codes)
• Obvious junk/test populations

Output: quality findings by domain with severity and remediation options (fix in source vs filter vs accept).

Note: profiling is a snapshot. Pair with a recommendation to start observability before migration so freshness and volume instability are visible over time: snapshots alone miss motion failures.

4) Mapping complexity score

Not every field map is equal.

Assess:

• COA and dimension transformation complexity (finance)
• Product/item model differences (ERP)
• Party and hierarchy model differences (CRM)
• Reference data rationalisation effort
• Custom fields with high usage vs sparse legacy noise
• Transformation rules likely to need business workshops

Output: complexity score by domain and a workshop effort estimate. This is one of the main drivers of delivery cost.

5) Target platform fit (when architecture is still open)

If the target is not fully fixed, readiness should challenge fit:

• Azure SQL / Managed Instance / other database targets
• ERP/CRM vendor constraints on open document patterns
• Analytics landing (including Fabric/lakehouse) vs operational cutover coupling
• Hybrid dual-run constraints

Output: fit notes and risks of wrong-platform lock-in (expensive to reverse).

6) Cutover strategy options and downtime envelopes

Model at least two viable patterns:

• Big bang vs phased by entity/site/module
• Freeze feasibility for operations and finance
• Delta strategy needs
• Weekend vs multi-day windows
• Rollback feasibility

Output: options with downtime envelopes, operational impact, and prerequisites (for example inventory count strategy).

7) Security, PII, and retention constraints

Should cover:

• Personal data in CRM/HR-adjacent objects
• Supplier/customer confidentiality
• Retention and minimisation decisions on history depth
• Access models for migration identities
• Residency constraints if relevant

Output: constraint log that prevents illegal or unpolicy-like “just copy everything” scope.

8) Team readiness and RACI gaps

Migrations fail when nobody owns proof.

Assess:

• Business owner availability for mapping and deep-dives
• Finance controller capacity for TB and subledger packs
• Integration owner coverage
• Whether a migration lead exists who is not only firefighting BAU
• Need for embedded capacity (data department model) vs partner-led delivery

Output: RACI draft and capacity risk rating.

9) Reconciliation and acceptance approach

A readiness assessment that ignores proof will underprice delivery.

Should define:

• Population definition approach
• Layers of reconciliation required by domain (reconciliation guide)
• Finance TB expectations if in scope (trial balance reconciliation)
• Draft acceptance criteria language for the future SOW

Output: proof approach that stops “job completed” being mistaken for done.

10) Budget and timeline sanity check

Compare ambition to norms:

• Complexity vs proposed dates
• SME time demand vs business calendar (peak trading, year-end)
• Dependency on upstream cleanse or observability work
• Contingency realism

Output: “date risk” narrative honest enough to be useful in a board pack.

Deliverables you should insist on

A serious assessment produces artefacts, not vibes:

What good costed options look like

• Minimal: highest risk accepted; narrow scope; faster but fragile
• Recommended: balanced proof, observability baseline, realistic cutover
• Strategic: deeper history, broader integration, stronger operating model uplift

If only one path is offered, you are being sold, not advised.

Example avoided-cost logic (how to read the business case)

Readiness fees are often justified by preventing a single major failure mode on a much larger programme. Illustrative mid-market logic:

Your numbers will differ. The structure should not: assessment cost versus priced risks on a programme that may already be heading to £200k-£1m+.

Treat this as insurance with artefacts: not as a guarantee. No assessment removes delivery risk entirely. It makes risk visible and commercially negotiable.

How readiness connects to observability and delivery

Recommended sequence for cost control:

1. Readiness assessment: shape, risks, options
2. Observability baseline on in-scope sources: stabilise inputs (cost case)
3. Delivery with methodology gates and reconciliation proof
4. Hypercare with evidence cadence, not only on-call

Skipping straight to delivery SOW on an unassessed estate is how organisations buy maximum late discovery at rush rates. That pattern is a common root of post-go-live failure narratives that actually began as pre-SOW blindness.

How to brief and evaluate a readiness supplier

Ask:

1. What artefacts will we hold at the end of week three?
2. How do you measure volumes and quality: access methods, sampling, tooling?
3. How do you score mapping complexity?
4. Will cutover options include operational freeze realism?
5. How will finance proof be treated if GL/subledgers are in scope?
6. Can our future SI reuse this pack without restarting discovery billing?
7. What do you explicitly not cover in the assessment fee?

Red flags: no access to source data, pure interview-only methods on complex estates, no risk scoring, no costed alternatives, and an immediate leap to multi-year platform proposals.

What Cyber Samurai’s assessment looks like in practice

Our Data Migration Readiness Assessment is built for UK SME and mid-market programmes: CRM, ERP, finance, warehouse, SQL/Azure moves, and M&A integration: typically over three weeks at £15,000-£22,000.

You should leave with a scored risk register, domain scorecard, roadmap, costed paths, and a business case pack you can take to sponsorship. From there, natural next steps may include migration delivery, observability stand-up, mapping acceleration, or governance support where ownership is the real blocker.

If you already know delivery will be partner-led, running readiness under your control first often improves SOW quality and reduces change-request theatre later.

Pay for clarity before you pay for motion

A data migration readiness assessment should cover landscape, scope, quality, mapping complexity, platform fit, cutover options, security/privacy constraints, team capacity, reconciliation approach, and commercial sanity: and it should hand you artefacts strong enough to steer a six- or seven-figure programme.

If your current plan is still “we’ll learn the data risks after the vendor starts,” you are planning to buy those lessons at delivery rates. Readiness is how you buy them earlier, cheaper, and with better choices still on the table.

Next step: Explore the Data Migration Readiness Assessment or talk to us about an upcoming CRM, ERP, or finance move.