Systems Consolidation and Data Migration Staffing for Companies Running Six Systems That Disagree
Two ERPs after an acquisition. Three places a customer address lives. A spreadsheet that finance trusts more than any of them. We staff the people who collapse that into one truth and move the history with it.
KORE1 staffs business systems consolidation and data migration projects with contract, contract-to-hire, and direct hire specialists who inventory, map, cleanse, and cut over disparate systems, averaging 17 days to first qualified submit and 92% one-year retention.
Last updated: August 9, 2026
A specialty manufacturer outside Grand Rapids called us in March about a data migration engineer. Two hours into the intake we weren’t talking about migration at all. They had bought a competitor in 2023, kept both ERPs running “temporarily,” and were now closing the books twice, in two chart-of-accounts, with 41 GL codes that overlapped and meant slightly different things.
Nobody had decided which system was going to die.
That’s the shape of most of these calls. The request arrives as a technical one, an ETL developer or somebody who knows the target platform, and underneath it is an unmade decision about which version of the company is true. You can’t map a field until somebody says which side wins.
Migration is the easy half. Deciding what survives is the work.
KORE1 has recruited IT staffing and enterprise systems talent since 2005, and consolidation programs have been a growing share of that desk since the middle of 2024. Some of it is merger driven. A lot of it is just twelve years of accreted software finally hitting a wall, usually at month-end close.
This page is about the second half of that sentence, because the merger cases get all the attention and the accretion cases are far more common. Nobody schedules a project called “we bought four things that don’t talk,” so it shows up disguised as a reporting problem, then as a headcount request, then eventually as a program with a board deadline attached.
Count the Systems, Then Count the Spreadsheets
Every consolidation starts with a list of applications. That list is always wrong, and it’s wrong in a predictable direction, because it captures what IT bought and misses what the business built.
The Grand Rapids client’s official inventory had nine systems on it. The real number, once we’d sat with the controller and the two people in customer service who actually keyed orders, was nine systems plus a shared drive with 60-odd workbooks, four of which were load-bearing.
One of those workbooks calculated freight allowances for their top eleven accounts. It had been maintained by the same person since 2016 and existed nowhere else.
Shadow systems aren’t a governance failure to be scolded about. They’re a map of every place the software didn’t fit, which makes them the single most useful document in the building during a consolidation, and the reason we push clients to staff a business analyst before they staff an engineer. Skip that step and the workbook gets discovered three weeks after go-live, by a customer, on an invoice.
Ask the question plainly. What do you keep outside the system, and why.
The Same Customer, Twice, and Only One Can Live
Master data people call the merged result a golden record. It sounds ceremonial. In practice it’s a field-by-field argument about which system was right, settled in advance by written survivorship rules so that nobody is making judgment calls at 2 a.m. during cutover. Here’s one account from a real merge, anonymised.
Five fields, three of them contested, and only one has an obvious answer. Payment terms went to the newer system because a signed contract sat behind it. Credit limit went the other way, because credit review lived on the acquirer’s side and always had. Ship-to addresses weren’t a contest at all, they were a union with a dedupe pass, which is the case people forget to write a rule for and then discover as eight thousand extra rows.
Six Seats a Consolidation Actually Needs
Almost nobody hires all six. Most teams have two or three of these already and call us for the gaps, which is the right way to use us.
Owns the decommission date, which is the only date that matters. A consolidation without a hard retirement date for the losing system isn’t a consolidation, it’s a second integration you’ll pay to maintain forever. Often an ERP implementation project manager.
Builds and reruns the load. The skill that separates them isn’t the tooling, it’s how fast they can rebuild the whole pipeline from source after somebody changes a rule in week nine. See ETL developer staffing.
Writes the survivorship rules and gets them signed off by the people who own the numbers. Quiet seat, enormous leverage. Usually a data governance analyst or a finance systems analyst wearing that hat.
Rebuilds every interface that pointed at the retiring system, and finds the three nobody documented. Platform-specific, so we screen for the stack you run. Boomi, MuleSoft, or custom API work.
Finds the shadow spreadsheets and translates a process into a testable requirement. Cheapest seat on the list and the one most often skipped, which is why the freight workbook gets discovered by a customer.
Proves the money still ties out after the load. Trial balance, open AR aging, inventory valuation, all matched to the penny against the legacy system before anyone signs off. Frequently a controller-track accountant, not an engineer at all.
The Weekend Is Not Where the Risk Lives
Cutover weekend gets all the anxiety and deserves almost none of it. By then the outcome is already set, because everything that will go wrong went wrong quietly during mapping and nobody caught it.
Rehearsals catch it. Full-volume dry runs, against real production data, with the reconciliation pack run at the end each time.
Three is the number we hear most often from people who have done this well, and the value isn’t in the third run, it’s in the delta between run one and run two, because that gap tells you whether your load is deterministic or whether somebody is hand-fixing rows and calling it a fix. Hand-fixed rows during a rehearsal are the single loudest warning sign in this work and they almost never get escalated, because the person doing it genuinely believes they’re helping.
The reconciliation pack itself is boring and non-negotiable. Trial balance to the penny. Open AR aging by bucket. Inventory quantity and value by location. Open sales orders and their remaining balances. If those five tie, you’re allowed to be nervous about the weekend. If they don’t, the weekend isn’t the problem.
Our ERP recruiters hear the unvarnished version of these programs from candidates constantly, which is a genuinely useful side effect of running a specialist desk. People will tell a recruiter what went sideways on their last cutover in ways they would never put in a case study.
Five Stages, and Only One of Them Is Technical
Timelines move with scope and data quality. The order doesn’t move, and staging your hires against it is how you avoid paying an engineer to wait.
- 01
Inventory
Every system, every interface, every shadow spreadsheet, and the name of the person who maintains each one. Ends with a written decision about what gets retired and when.
- 02
Map
Field-level crosswalk from each source to the target, with survivorship rules for every contested field. This is the document the whole program hangs from.
- 03
Cleanse
Dedupe and repair at the source where you can, in the pipeline where you can’t. Fixing it in flight means fixing it again on every single rerun.
- 04
Rehearse
Full-volume dry runs against production copies, each one ending in the same reconciliation pack. Two or three rounds, timed, so you know what the real window is.
- 05
Cut over and retire
Freeze, load, reconcile, release. Then actually turn the old system off, because a read-only legacy instance left running for “just in case” tends to still be running four years later.
Everyone Has Done a Migration. Ask About the Rollback.
Résumés in this space all look similar, because almost every enterprise systems person has been near a migration at some point, and the language candidates reach for to describe it stays remarkably consistent whether they set the rules or were handed a spreadsheet of rows to clean. The screen has to separate the people who owned an outcome from the people who were assigned some rows.
Two questions do most of that work.
The first is about survivorship. Tell me about a field where two source systems disagreed, and how the decision got made. People who genuinely held the seat name the field, name the rule, and name who signed off, usually in under a minute. People who were adjacent to it describe a process.
The second is the rollback. What was your abort criteria, who could call it, and did you ever call it. A surprising share of strong candidates have called one, and they’ll tell you about it without flinching, because deciding to stop at 3 a.m. on a Saturday is the most senior thing anybody does on these programs.
We also check the platform honestly rather than generously. Somebody who has moved data into NetSuite is not automatically the person to move it into SAP S/4HANA, and the reverse is just as true. If your target is a specific platform, we screen against that platform. If you’re not sure yet what the target is, that’s a different conversation and probably starts at ERP vendor selection advisory or an enterprise architect.
Three Ways to Take the Bench
Same recruiters, same network. The shape follows how long the program runs and what happens to the seat afterwards.
Contract & Contract-to-Hire
Migration engineers, integration developers, and analysts on a KORE1 W-2 for the length of the program, typically four to nine months. Converts cleanly when a seat turns out to be permanent.
Contract Staffing →Direct Hire
For the seats that outlive the project. Data stewardship and integration ownership don’t end at go-live, and backfilling them later costs more than hiring them now.
Direct Hire details →Project & Statement of Work
A scoped team against defined deliverables, priced to an outcome. Fits a board-mandated decommission date or a carve-out with a TSA clock running.
Project Staffing →Common Questions
What does a business systems consolidation project actually involve?
Business systems consolidation means retiring overlapping applications onto a single system of record, which involves five stages. Inventory the systems and shadow spreadsheets, map fields between them, write survivorship rules for contested data, cleanse and rehearse the load, then cut over and decommission.
The part that surprises people is how little of it is technical. Two of the five stages are decisions, one is cleanup, and only the load itself is engineering work. That ratio is why a program staffed entirely with engineers tends to stall around week six.
Can’t our ERP implementation partner just handle the data migration?
Partly. Implementation partners are good at loading data into the platform they know, and that’s real value. What they usually won’t do is dig through your legacy source, arbitrate which system wins on a contested field, or hunt down the shadow spreadsheets.
Their statement of work almost always says you provide clean, mapped data in a defined template. Read yours. The gap between “we’ll migrate your data” and “you’ll deliver us a mapped extract” is where a large share of budget overruns actually happen, and it’s a gap you fill with your own people, not theirs.
How long does consolidating two systems take?
Four to nine months is the common band for a mid-market consolidation of two systems, running roughly four to six weeks on inventory and mapping, six to twelve on cleanse and build, and four to eight on rehearsals and cutover.
Data quality moves that number more than anything else. A clean source with one entity and a single chart of accounts can land near the bottom of the range. Two entities, two charts, and eleven years of history will push past it. Multi-entity programs with international subsidiaries run past a year routinely and should be planned that way from the start rather than discovering it in month five.
What should we budget for consolidation and migration staffing?
Across KORE1’s 2026 consolidation placements, contract data migration engineers and integration developers bill between $85 and $165 an hour, with senior program leads and enterprise architects running $150 to $250. A three-person core team across six months usually lands in the mid six figures.
Weigh that against what the duplicate stack already costs you. Two ERPs means two sets of licences, two closes, two upgrade cycles, and a finance team spending its first week of every month reconciling instead of analysing. Most clients we work with find the annual carrying cost of the second system covers a meaningful slice of the program before they count anything else.
What usually goes wrong?
Scope discovered late. The single most common failure is finding a load-bearing system or spreadsheet after mapping is finished, which resets the crosswalk and pushes the whole timeline.
Second most common is a rehearsal that gets hand-fixed. Somebody patches 400 bad rows manually to make a dry run pass, the run looks green, and the underlying rule never gets corrected. Third is no decommission date, which turns a consolidation into a permanent integration. All three are process failures rather than technical ones, and all three are cheap to prevent and expensive to discover.
Do we have to re-implement, or can we consolidate onto what we already run?
You can often consolidate onto an existing instance, and it’s usually cheaper. The test is whether your current configuration can absorb the other business without being rebuilt, which comes down to entity structure, chart of accounts, and item master conventions.
If the acquired business has a genuinely different operating model, a discrete manufacturer folded into a distributor for instance, absorbing it into an instance configured for the other one tends to produce a compromise that serves neither. That’s the case where a fresh implementation is the honest answer even though it’s the more expensive one.
Who owns data quality once the project ends?
Somebody named, in the business, with time protected for it. Consolidations create clean data exactly once, on go-live day, and it starts degrading immediately unless a person owns the rules that keep duplicates from re-entering.
This is the seat clients most often try to leave as a shared responsibility, and shared responsibility here means nobody. Nine months later the duplicate count is back where it started. If you only convert one contract seat to permanent out of the whole program, make it this one, and give whoever holds it the authority to reject a record rather than just report on it.
Tell us which system you’re retiring and when. We’ll size the bench against that date.
One intake call is usually enough to scope the roles, stage them against your timeline, and give you a real first-submit date.
Talk to a Consolidation Recruiter →