Skip to main content

Systems integration

Data migration that keeps the history, not just the records

Moving data between systems is where most replacement projects go wrong. Done properly it is rehearsed, reconciled and reversible — not a weekend and a held breath.

The situation

The riskiest part of replacing a system

Migration is usually scheduled last, estimated optimistically and rehearsed once. That is why it is the stage that most often forces a go-live to be abandoned.

  • Duplicate records nobody has agreed how to merge
  • Historical data in a format the new system has no field for
  • Free-text fields holding information that should be structured
  • No agreement on what counts as a successful migration
  • A cutover plan with no tested way back
  • A legacy system nobody wants to keep, but nobody dares switch off

What it covers

What a migration covers

  • Profiling

    Understanding what the data actually contains, as opposed to what the schema claims, which is where the surprises live.

  • Cleansing and de-duplication

    Duplicates, gaps and contradictions surfaced for a decision rather than silently carried into the new system.

  • Mapping

    Field-by-field mapping including the awkward cases — data with no home in the new model, and fields repurposed years ago.

  • Rehearsal runs

    Full migrations into a test environment, repeatedly, until the run is boring and its timings are known.

  • Reconciliation

    Evidence that what arrived matches what left, by count and by value, rather than a spot check and an assumption.

  • Cutover and rollback

    A sequenced plan for the switch, and a tested way back if the criteria are not met on the day.

How we work

How a migration runs

The principle is simple: by the time you do it for real, you should have done it several times already.

  1. Profile and agree

    Establish what the data holds and agree what a successful migration means, in numbers, before anything moves.

  2. Map and cleanse

    Build the mapping, resolve the duplicates and decide what happens to data with nowhere to go.

  3. Rehearse

    Run the full migration into test, reconcile, fix, repeat. Each run should be less eventful than the last.

  4. Cut over

    Execute against the plan, reconcile against the agreed criteria, and keep the rollback available until they are met.

Outcomes

What you are left with

  • History preserved, not just current records
  • Duplicates resolved by decision rather than by accident
  • Reconciliation evidence that the migration was complete
  • A cutover that has been rehearsed rather than attempted
  • A tested rollback, available until the criteria are met
  • A legacy system that can actually be switched off

Platforms and tooling

What we work with

Sources

  • SQL Server
  • Oracle
  • MySQL
  • Access
  • Excel
  • Legacy and mainframe extracts

Targets

  • Salesforce
  • Dynamics
  • Blackbaud
  • SAP
  • PostgreSQL
  • Cloud data platforms

Tooling

  • ETL pipelines
  • Azure Data Factory
  • SSIS
  • Custom transformation

Named as platforms we work with, not as formal partnerships.

Common questions

Questions we are usually asked

  • Longer than most plans allow, because the effort is in profiling and cleansing rather than in the transfer itself. The move might run in hours; agreeing what to do with twenty years of inconsistent records is what takes the time.

Talk to someone who has built this

Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.

Book a free consultation

Tell us what you need

No obligation, and nothing is shared outside Geecon Global.

Not sure where to start?

We will use these details only to reply to you. See our privacy policy.

Related

Where this usually connects