Move your datafrom one system to another
A new CRM, ERP or HR system needs the data from the old one, remapped to fit its own structure. We extract and remap that data, and keep doing so for as long as the old and the new system run side by side.
- Old and new side by side
- Data from the old system keeps reaching the new one, remapped, for as long as both are in use.
- Remapped, not just copied
- Old fields, codes and structures are translated to those of the new system, so the data fits the way it works.
- Checked on every load
- Each load is tested row by row against the old system, so differences are found before anyone works with the data.
The problem
Your new system needs your old data
A new system gets a project team. The data usually gets nobody. Yet it has to leave the old system, fit the new one and stay up to date while people still work in both. Get that wrong, and the new system goes live with gaps nobody trusts.
Common symptoms
You need to load the historical data into the new system, but the new vendor cannot do it for you
Fields, codes and structures in the old system do not match those of the new one
During the switch both systems are operational at the same time, so a single import does not cover your needs
What this costs you
Records added or changed in the old system after the import never reach the new one
Staff enter the same data twice, and the two systems slowly drift apart
Users stop trusting the new system the first time its figures differ from the old one
How we move your data
From old to new, continuously remapped
A vendor's import tool moves your data once and stops there. We build a route that extracts the data from the old system, remaps it to the structure of the new one and checks it on the way. That route runs automatically and keeps going for as long as both systems are in use.
Extracted from the old system
Focus
We write extraction code for the system you are leaving, standard or custom-built, and connect it to the new one. The data comes out in full, and the extraction can run again whenever it is needed.
Key outputs
Extraction code for the old system, a connection between the old and the new system, and an overview of the data involved.
Remapped to the new system
Focus
Fields, codes and structures from the old system are translated to the ones the new system uses. On the way, the data is held in a staging database and each load is tested against the source.
Key outputs
A mapping from old to new, a staging database and test results per load.
Kept running while both are in use
Focus
Automated runs repeat the extraction and remapping, so records added or changed in the old system keep reaching the new one for as long as both are in use. After hypercare, the runs can continue under Managed Services.
Key outputs
Automated runs that can be rerun after a correction, hypercare after go-live and handover documents.
Capabilities
What we deliver
The parts of every system switch, from the code that reads the old system to the automated runs that keep the remapping going.
Data extraction
Code written for the system you are leaving, so the data comes out in full and the extraction can be repeated.
Link between old and new
A connection between the old and the new system. Where no standard connector exists, we build one ourselves.
Remapping to the new structure
Fields, codes and structures from the old system translated to those of the new one, agreed with the people who know both.
Staging database
A database between the two systems, usually PostgreSQL, where data is held and checked before it is loaded into the new one.
Automated runs
Runs, for example on Azure Function Apps, that keep the extraction and remapping going and can be rerun after a correction.
Testing against the source
Each load compared with the old system row by row, with the results recorded.
Where it creates value
Who benefits most
Practical value for the teams that carry the most complexity.
CIO / IT
IT leaders replacing a CRM, ERP or on-premises platform while the business keeps working.
- Teams can keep working in the old system while the new one is rolled out
- No double entry while parts of the business still work in the old system
- Specialists carry the data work while your team keeps the current systems running
Sales and customer service
Teams moving from an old CRM to a new one, often one team or region at a time.
- Customers, contacts and history remapped to the structure of the new CRM
- Customers added or changed in the old CRM keep reaching the new one
- Teams switch when they are ready, not all on one weekend
Finance / Control
Finance leaders moving to a new ERP who need the financial history in it complete and correct.
- Financial records checked against the old system on every load
- Old codes and cost centres translated to the structure of the new ERP
- The cost of each phase is fixed before it starts
HR and other departments
Departments running their own system switch, such as a new HR system, without a data team of their own.
- Data specialists who take the data work off the project team
- Employee data remapped to the structure of the new system
- Employee changes made in the old system during the switch still arrive in the new one
Data / BI teams
Data teams moving a database or platform to the cloud while reports keep reading from it.
- What depends on the old platform is mapped before anything moves
- Reports keep working while the old and the new platform are both in use
- New data in the old platform carried across until the last report has moved
Less relevant if...
Another route is likely to fit better when:
- The new vendor's standard import covers all your data and the old system is switched off at once
- Machines or devices need connecting to your ERP, CRM or other software: see IoT & Hardware Integration
- An AI use case drives the move and its data must be ready first: see AI Readiness
- Your own team has the time and the experience to run the move
How it works
A practical delivery approach
Every engagement follows a clear path from diagnosis to delivery and handover.
Scope
On site, we agree which data moves from which system to which, what depends on it, which history comes across and how long the old and the new system are expected to run side by side.
Agreed scope, an overview of the data and dependencies involved, and a phase plan with a fixed price per phase.Design
We design the route: how the data comes out of the old system, how its fields, codes and structures map to the new one, where it is held and checked on the way, and how often the runs repeat while both systems are in use.
Route design, the mapping from old to new and the test approach.Build and test
We write the extraction code, build the connection and the staging database, and set up the automated runs. Each load is tested against the source.
Extraction and remapping code, automated runs and test results per load.Acceptance
You sign off the route against the checks agreed in scoping: the data complete in the new system, the mapping correct and the runs working. Anything not yet right is fixed before go-live.
Sign-off against the agreed checks and an agreed go-live.Hypercare and handover
After go-live, the experts who built the route stay on hand to resolve issues while the runs settle in. We then hand over the code and documentation. If both systems stay in use for longer, the runs can continue under Managed Services.
Hypercare after go-live, handover documents and, if you want it, an SLA for the runs.
Proof & trust
Results that speak for themselves
Old and new side by side
Data from the old system keeps reaching the new one, remapped, for as long as both are in use.
Remapped, not just copied
Old fields, codes and structures are translated to those of the new system, so the data fits the way it works.
Checked on every load
Each load is tested row by row against the old system, so differences are found before anyone works with the data.
Any system you run
CRM, ERP, HR system or on-premises database, standard or custom-built. The extraction and remapping are written for your systems.
A usable result every phase
Each phase ends with something your team can use: live results, a demo and handover documents.
Knowledge stays with you
Handover documents, plus training and pairing where your team will run the result, so the knowledge of how old maps to new stays in house.
Example engagement
What it looks like when it works
How an engagement like this typically runs. An illustration, not a client result.
Context
Example: a wholesale company moving from an old CRM to a new one region by region, so both CRMs stay in use while the switch rolls out.
Challenge
Customer records, contacts and order history have to move to the new CRM, but the two systems store them differently. Regions that have not switched yet keep adding and changing customers in the old CRM, and the vendor's import tool offers a single load.
Solution
We write extraction code for the old CRM, agree the mapping of fields and codes with sales and IT, and build a route through a staging database where each load is checked against the source. Automated runs keep remapping new and changed records into the new CRM until the last region has switched.
What you get
Mapping from old CRM to new
Fields, codes and structures of the old CRM translated to those of the new one, agreed with sales and IT.
Automated remapping runs
Runs that keep bringing new and changed records from the old CRM into the new one while both are in use.
Test and handover records
Test results per load, hypercare after go-live and handover documents.
Context
Example: a manufacturer replacing its ERP, with finance moving to the new system first while production keeps working in the old one.
Solution
We map what depends on the old ERP, extract its data, remap codes and structures to the new ERP and load the history in steps, each tested against the source. After go-live, automated runs keep bringing in what is still recorded in the old ERP, and after hypercare the client keeps the runs going under Managed Services until production has switched too.
What you get
Dependency overview
The data, reports and processes that rely on the old ERP, and the order in which they move.
Tested history in the new ERP
Customer, supplier and financial history remapped and tested against the source.
Runs under Managed Services
The automated runs continue under an SLA while production still works in the old ERP.
Frequently asked questions
Your questions, answered
Yes, and they usually do. Teams, sites or processes often keep working in the old system after the new one has gone live. We build the route so that it keeps extracting data from the old system and remapping it into the new one for as long as both are in use. The data moves in one direction, from old to new.
The next run picks it up. The automated runs repeat the extraction and remapping on the schedule agreed in the design, so new and changed records in the old system reach the new one, checked against the source on the way.
For as long as you need both systems. During hypercare after go-live, the team that built the route keeps it running and resolves issues. After that, the runs can continue under Managed Services, as an SLA, or your own team can take them over with the handover documents, until the old system is switched off. You decide when it stops.
Every load is tested row by row against the source in a staging database between the old and the new system, so differences are flagged before the data is loaded into the new one. Before go-live, you sign off the result against the checks agreed in scoping.
Virtually any system you run, standard or custom-built. The old system can be a CRM, an ERP, an HR system, another business system or an on-premises database, and the new one a business system or a cloud platform. We write the extraction code for the system you are leaving, and where no standard connector exists between the two, we build one ourselves.
Access to the old and the new system, a sponsor who can decide on scope, someone who knows how the old system is used, a contact in the team implementing the new system, and people who can confirm the mapping from old to new.
In fixed-price phases, agreed after scoping, each ending with live results, a demo and handover documents. Additional advice outside a phase can be billed by the hour. After hypercare, the runs and support can continue under Managed Services, as an SLA. You can work with SolvX directly or through one of our partners.
You own your data, your client-specific code and the documentation. SolvX keeps the rights to its generic building blocks; the contract sets out the details. The extraction code, the mapping, the tests and the handover documents are delivered to your organisation, so your team can see how every part of the move was done.
When the new vendor's standard import covers all your data and the old system is switched off at once, you may not need us. When machines or devices need connecting to your ERP, CRM or other software, look at IoT & Hardware Integration. When an AI use case drives the move and its data must be ready first, start with AI Readiness. And if your own team has the time and the experience, it can run the move itself.
Next step
Where do you want to start?
Pick the path that matches where you are today. Both begin with a conversation.
Moving to a new system?
Tell us which system you are leaving, where your data needs to go and how long both systems will be in use. We look at the data involved and what depends on it, and propose the route in fixed-price phases.
- Go through the data in the old system and what depends on it
- Discuss how the data maps to the new system
- Receive a proposal in fixed-price phases
No obligation. Typical response within 1 business day.
Start with an assessment
Not ready to commit to a pilot? A 2 to 4 week assessment maps your current state and identifies the highest-value starting point, with no obligation to proceed further.
- Map your current situation and pain points
- Identify 2 to 3 high-value improvement opportunities
- Get a recommended pilot scope and expected outcomes
No obligation. Typical response within 1 business day.
You might also be interested in
Related solutions
Data Quality Monitoring
Alerts your data team when a pipeline or data test fails, with lineage that shows what an incident hit.
ExploreIoT & Hardware Integration
Scales, scanners, sensors and machines linked to your ERP, CRM or warehouse system, so every reading is booked automatically.
ExploreManaged Services
Ongoing SLA support for the data platforms, dashboards, AI solutions and apps SolvX builds.
Explore