Dataracity
Legacy SQL → Salesforce migration

Migrating legacy on-prem SQL data into Salesforce without recreating the same problems

Years of disorganized on-prem customer data restructured into clean, Salesforce-ready records — so the move fixed the problem instead of relocating it.

MoveOn-prem SQL → Salesforce
FocusTransformation layer
MethodCode + API loads
OutputRepeatable pipeline
Results
80%Reduction in manual data handlingPost-migration
3kSource records cleaned and mappedStandardized to Salesforce
90%Data usable with zero manual cleanupAt cutover
14 wksKickoff to go-liveIncluding validation
Software used
SalesforceTarget platformSQL Server (on-prem)Source systemsSalesforce APIsControlled loadsCustom transformation codeCleaning and reshapingMicrosoft FabricSequencing
Related services
The migration, move by move

Out of the legacy estate, into a shape Salesforce accepts.

Six moves took years of inconsistent customer data from on-prem SQL into Salesforce — most of the work happening before anything touched the new platform. Follow the pipe.

Scroll to run the migration
Where it startedLegacy on-prem SQL
01
01The challenge · The wrong shape

The system worked. The data just wasn’t Salesforce-shaped.

The on-prem system did what it was built to do — what it didn’t do was hold data in a shape that could move into Salesforce. Records were inconsistent, formatting varied across years of manual entry, and none of it was structured the way Salesforce expects.

Inconsistent records across years of manual entryFormatting varied field by field, year by yearNo alignment to Salesforce objects or fields
Before · source vs target shapeMismatched
Free-text, no standard
Formats drift year to year
Required fields never captured
TargetSalesforce objects & fields
Direct-load readinessNot ready

The legacy system held what it needed. Salesforce expects something else entirely.

02
02The context · What a lift-and-shift would cost

Moving it as-is would have rebuilt the same mess in a new system.

The decision to migrate had been made, but the data itself wasn’t ready. Moving it as-is would have rebuilt the same mess inside a new system — this time inside the platform the business was counting on to fix it.

Migration decision made, data not readyAs-is load = same mess, new platformThe platform expected to fix it would inherit it
Before · the lift-and-shift pathRebuilds the mess
Erroneous recordscarried over
Inconsistent text and formattingcarried over
Cleanup work after go-livemanual
Trust in the new platformat risk

A straight transfer carries every defect across. New platform, same problems.

03
03The approach · Extraction

Pull the data out before deciding anything about it.

Data was extracted directly from the legacy on-prem SQL systems — a stable source to reason about rather than a moving target, and the first step in a sequence where nothing reached Salesforce untested.

Direct extraction from on-prem SQLSource captured as a stable baselineNo writes to the target until validated
Approach · extractionBaselined
01Legacy SQLOn-prem customer data
02ExtractDirect, full baseline
03ProfileVariations catalogued
04StageHeld before transform
No writes to Salesforce at this stage

A stable source to reason about — nothing reaches Salesforce untested.

04
04The approach · Structured data models

Structured models aligned to how Salesforce actually holds information.

Data models were designed against Salesforce’s object and field architecture, so every variation in the source data had one defined destination — including the fields Salesforce required that the legacy system never captured.

Models aligned to Salesforce objects and fieldsEvery source variation mapped to a destinationRequired fields derived, not left blank
Approach · target data modelAligned
Source
Legacy tablesAs captured, variations and all
Mapping
Field-by-fieldEach variation routed to its target
Target
Salesforce objectsObject and field architecture respected
Fields Salesforce requires but the source never captured, derived

Every variation in the source has one defined destination in Salesforce.

05
05The approach · Where the real work sat

Most of the effort sat in transformation, not transfer.

Transformation logic was built in code to clean and reshape the data at scale: erroneous records removed, inconsistent text standardized, required fields derived, and every source variation mapped to the right place in Salesforce.

Erroneous records removedInconsistent text standardized at scaleEvery variation mapped to the correct Salesforce field
Approach · the transformation layerWhere the work sat
Remove
Erroneous recordsDropped rather than migrated
Standardize
Inconsistent textOne format, applied at scale
Derive
Missing fieldsRequired values reconstructed
Logic written in code, versioned and re-runnable

What most migrations underestimate — and what separates one that sticks from one that moves the problem.

06
06The approach · Orchestration and loading

API loads, sequenced by pipelines that can run again.

Integration ran through Salesforce APIs for controlled, repeatable loads, orchestrated by pipelines that managed and sequenced the whole migration flow — the same pipeline the business can re-run for future loads.

Salesforce API integration, controlled loadsOrchestrated pipelines sequence the flowRe-runnable for future migrations and loads
Approach · orchestrated loadingRepeatable
01SequencePipelines order the flow
02ValidateChecks before each load
03LoadSalesforce APIs, controlled
04Re-runSame pipeline, future loads
Idempotent, controlled loads
Orchestrated end to end

A migration structure that produces a consistent result every time it runs.

Where it landedSalesforce
We engaged Dataracity to lead the design and recommendation phase of one of our client's enterprise data architecture projects on the Microsoft platform. From the outset their expertise was evident — they introduced us to Microsoft Fabric and provided a robust framework rooted in industry best practices. Beyond high-level strategy, they delivered tangible assets including detailed system architecture diagrams, data flow charts, and comprehensive price modeling. Their technical execution is just as impressive as their strategic planning. I highly recommend Dataracity for any organisation looking to modernise their data stack with precision and clarity.
Shelly JantzenShelly JantzenFounder · E2 Consulting
The people who built it

Team responsible.

A small delivery team, named and accountable from kickoff to go-live.

  • Luke Matthews, Co-Founder, Head of Project Delivery & Data Architecture at Dataracity

    Luke Matthews

    Co-Founder, Head of Project Delivery & Data Architecture

  • Amanda Buthelezi, Co-Founder, Project Lead (BI & Data Strategy) at Dataracity

    Amanda Buthelezi

    Co-Founder, Project Lead (BI & Data Strategy)

  • Estella Doulis, Business Intelligence Consultant at Dataracity

    Estella Doulis

    Business Intelligence Consultant

How we plan a cloud migrationMigration approach, end to end
Same move, different platform?

A migration should fix the data, not relocate it.

Bring us your source systems and your target platform. We'll map the data models, the transformation work, and the load sequence in one conversation.

30 minutes No obligation Data migration specialists