Through 2027, more than 70% of recently implemented ERP initiatives will fall short of their original business goals. The largest study of big IT programs, from McKinsey and the University of Oxford, found they run 45% over budget and 7% over schedule on average while delivering 56% less value than promised. Poor data quality alone costs the average organization at least $12.9 million a year. And when one of the largest public ERP programs on record hit its first operating milestone 22 months late, the reason named in the audit was, in part, the effort to convert data from legacy systems.
Almost none of that is a software problem. On most programs the software works. What fails is the two workstreams that decide whether the software ever holds real data and talks to the systems around it: data conversion and integrations. They are the quiet middle of the project. They do not demo well, they get little executive airtime, and they are the first place a program borrows time from when it falls behind. Then they take the go-live date down with them.
This is the field guide I use on a live program. It is written for the client-side program leader, not the System Implementer (SI) and not the technical team. It is system agnostic. The examples lean on Workday and Oracle Cloud because that is where I have spent the most time. The discipline is the same on SAP, Dynamics, or anything else. Throughout, you will find notes from real engagements, fully anonymized, and one move that changes the outcome in each area.
The software is rarely the risk. The data going into it and the connections coming out of it are, and both fail for management reasons: unclear ownership, wrong sequencing, no accountability for data quality, and testing that gets compressed until it proves nothing. Fix the management and the technology follows.
1. The two workstreams that decide the date
Every ERP program has a headline story: one system, cleaner processes, better reporting. That story hides how much of the work is plumbing. You are pulling decades of data out of systems people have forgotten how to explain, reshaping it to fit a new model, and rebuilding every handshake to the banks, carriers, tax engines, and downstream applications that keep the business running. None of it shows up in a demo. All of it shows up on cutover weekend.
Conversion and integrations belong together because they share a calendar and they share a failure mode. You cannot test an integration properly until the data behind it is converted and stable, so the conversion schedule drives the integration schedule. And both fail the same way: they get treated as technical tasks the SI will handle, so nobody on the business side owns the outcome until the outcome is a problem. The number that matters has nothing to do with how many modules you are deploying. It is how many data objects you are converting and how many interfaces you are standing up, because that is the count that sets your real critical path. The stakes sit in the tail. One in six large IT projects becomes a genuine black swan, a cost overrun near 200%, the kind of number that can threaten the company itself. Conversion and integrations are where those tails get made.
Put conversion and integrations on the program's critical path in week one, with their own lead, their own plan, and their own status in every steering review. If they are buried inside a functional workstream, they are already losing.
The count you were given is not the real count. On one program, discovery listed 50 integrations. The real number was closer to 90 once we mapped every handshake to banks, carriers, tax engines, and downstream apps. The plan was built on the wrong number from day one, and every date downstream inherited the error.
2. Decide what converts before you decide anything else
The first real decision in conversion is scope, and it is a business decision dressed up as a technical one. You do not have to convert everything. Most programs convert far more history than the business will ever use, pay for it in schedule and risk, and then archive the legacy system anyway. The cleaner default is to convert open balances and active master data, and to leave closed history where it sits, in a read-only legacy archive you can query when an auditor or a dispute requires it. History gets converted only where a law, a regulator, or a live business process actually needs it in the new system.
There is a third bucket worth naming: start fresh. Some master data is better rebuilt clean in the new model than converted, because the legacy structure no longer fits how the business will run. A redesigned chart of accounts, a rationalized set of cost centers, or a cleaned supplier master is often worth building new rather than dragging forward. Archiving unneeded data before cutover costs you nothing either. It shrinks the volume you move during the go-live window, which shrinks the downtime and the risk on the single weekend where risk is most expensive.
The dirtiest data is the oldest data. The instinct to bring it all over so we have it always costs more than it looks. The records nobody has touched in 7 years are the ones with the broken references, the retired codes, and the fields that meant something to a system that no longer exists. You pay to clean them, convert them, and reconcile them, and then no one ever opens them.
3. Data quality is your job, not the SI's
Here is the sentence that saves programs. The implementation partner is not responsible for cleaning your data. They will build the extracts, the mappings, and the loads. They will profile the data and flag what looks wrong. But they cannot know that a cost center is dead, that two vendor records are the same company, or that a worker marked active left in March. Only the business knows that. Independent advisors put it the way I wish every sponsor heard on day one: your software vendors and implementation partners are not responsible for your data, and if you hand them dirty data and assume they will fix it, you are setting up the next failure.
Cleanse at the source whenever you can, before the data ever enters the conversion process. Fixing it in the legacy system is the cleanest option because it fixes the record everywhere it lives. Fixing it in the transformation rules is a fallback for when the legacy structure simply cannot produce what the new system needs. Fixing it after go-live, inside the new system, is the option of last resort and the one that quietly becomes permanent. Start cleansing before the first mock conversion and keep going through every cycle, because data decays while you work and new bad records arrive every day the legacy system stays live. Profiling comes first, because the risk in a conversion hides until it is expensive. Poor data quality usually surfaces late, as load failures in the target system at the worst possible moment, unless you profile the source early. And do not chase perfect. No organization needs, wants, or will pay for perfect data. Set a target, measure against it, and move.
10% of active was not active. On a recent program, 10% of the active worker records were duplicates or carried termination dates that contradicted payroll history. That is compliance and payroll-tax exposure, not a spreadsheet problem. Discovery never surfaced it. Profiling and business review did.
4. Put a name on every data domain
The single most common root cause of failing conversions is that no one person owns the data. Data governance has a clean model for this. A data owner is a senior business stakeholder who is accountable for a domain and holds sign-off authority. A data steward is the practitioner responsible for day-to-day quality, the mapping rules, and validating the converted results for that domain. A data custodian is the technical role that operates the extract, transform, and load mechanics. The SI is your custodian. The SI is neither your owner nor your steward. Accountability for whether the data is correct and fit for purpose sits with your people and cannot move to the vendor.
When that structure is missing, the work does not stop, it just fails quietly. Every team assumes another team has the validation rule. The load fails, and three groups each explain why it is not theirs. Naming one accountable owner per domain, with a date on every open item, ends that pattern faster than any tool.
One owner stopped the failures. On one program this year, finance and procurement data loads kept failing during conversion. The cause was not the software. No single person owned the validation rules across the modules, so every team assumed another had it. We named one owner, gave each item a date, and the failures stopped. The fix cost nothing.
5. Design the mapping before you load anything
Conversion is reconciliation, not loading. The mapping specification is where you decide what correct means, and a load built on a vague mapping produces defects you cannot even diagnose. Every field in the new system needs a decision about where its value comes from. There are only a few patterns. A direct move maps straight across, maybe reformatted. A translation rule is legacy data that needs logic before it fits. Defaulting is when the new system requires a field the legacy system never captured, so the business defines a valid default. A crosswalk handles the one-to-many and many-to-one cases.
The hard cases are the ones with no clean source. A required target field with no legacy equivalent needs a business-owned default, not a developer's guess. Duplicate values across legacy systems force a decision about the system of record before anything loads. Get these decisions in writing, owned by the steward, and you have a mapping you can reconcile against. Skip them and you have a load that worked and data nobody trusts. Two details pay off later. Build crosswalk tables for any re-keyed identifier, such as a new vendor ID, so users can still tie a new record back to the old one after go-live. And bake validations into the mapping spec itself, including dependency checks like loading vendors before the purchase orders that reference them.
Treat the source-to-target mapping as a signed design artifact, one owner per object, every defaulting and system-of-record decision made by the business in writing before the first load. The mapping is the contract for what converted correctly means.
6. Mock conversions: run several, reconcile every one
A single right-first-time conversion is itself a named program risk. The practice that de-risks it is iterative: run several mock conversions in production-like environments, and keep running until the results say the data and the tooling are ready. At least one mock should run on production-scale data, in both quality and volume, so you find the volume and performance problems before cutover, not during it.
Each mock has to prove three things, and completing is only the first. Reconciliation reports tie the data extracted from legacy to the data loaded in the new system at a control-total level. Item-level validation checks individual records by hand and is the exit criterion for moving on. End-to-end process validation runs a real business process, requisition to payment or hire to pay, on the converted data. Set entry and exit criteria for every cycle and run a lessons-learned after each one to attack root causes. On my programs the bar is concrete: run at least three mock conversions, hold critical defects to near zero, and require Finance to reconcile control totals to the dollar before any data is called go-live ready. Under 2% error on the final mock is the floor, not the goal.
No mock passes until control totals reconcile, item-level validation clears, and every critical defect is closed. Publish the exit criteria before the cycle starts so nobody can redefine done under deadline pressure.
7. Nearly every program underestimates its integration count
Integration count and complexity are underestimated on nearly every program. The application estate around a modern ERP is enormous and mostly disconnected. The average organization now runs close to 957 applications, and only about 27% of them are connected to each other. So when a program starts mapping the systems the ERP must talk to, the universe is large and most of it was never integrated before. Real programs carry the weight of this: on public-sector ERP work, one Oracle Cloud program delivered more than 100 integrations, and one Workday program delivered 64. Dozens to a hundred-plus interfaces is normal for an enterprise deployment.
A useful taxonomy keeps the inventory honest: inbound feeds (time, benefits enrollments, bank returns), outbound feeds (payroll to the provider, GL to the bank, files to tax and reporting), and bidirectional links (CRM, procurement, EDI). Every interface also has two owners, one on each side, and that is a scheduling risk before it is a technical one. An interface is only as ready as the slower of its two sides, so confirm the counterpart's availability and test schedule before you commit your own dates. The interfaces that slip are rarely the hard ones. They are the ones where the other side was never asked.
Build the integration inventory yourself, from the process map, not from the SI's discovery list. Rate every interface by criticality and by cutover timing, and treat the close-critical ones, payroll, bank, tax, GL, as their own mini projects with named owners on both sides.
8. Pick an integration architecture on purpose
How you connect systems is a decision with a long tail. Point-to-point wires each system straight to each other system. It is fast and cheap for a single connection, and it is a trap at scale: the number of possible connections grows with the square of the systems, so five systems can have ten links and twenty systems can have 190. Middleware, or an integration platform as a service (iPaaS), connects each system once to a central platform that handles routing, transformation, monitoring, and error handling. API-led connectivity is the modern layered form of the hub, organizing interfaces into reusable system, process, and experience layers so one connection built once is consumed many times.
The market has voted with its budget: iPaaS is the largest segment of the integration middleware market, with revenue past $9 billion in 2024 and a forecast beyond 17 billion by 2028. That does not mean a platform is right for every program. It means that if you are carrying dozens of interfaces you will maintain for years, the total cost of hand-built point-to-point connections almost always loses to a hub once you count monitoring, error handling, and the day someone has to change a field. Reserve point-to-point for the genuinely simple and stable, and put the close-critical, high-volume interfaces on a platform with real error handling and monitoring.
The interface no one could see was the one that broke. Hand-built integrations rarely fail by never working. It is that when one quietly breaks, a hand-built link with no monitoring lets it fail unnoticed far longer than it should. By the time the error surfaces it is a reconciliation problem, not an alert.
9. Sequence the build and test against the conversion calendar
You cannot reliably test an integration on data that is not yet converted and stable. Testing an interface against unconverted or unstable data is a way to generate noise. When a test fails, you cannot tell whether the fault is the data, the mapping, or the interface logic. That is why data reconciliation after conversion is an entrance criterion for the next test phase, not a nice-to-have. The same discipline demands a configuration freeze: if functional teams keep changing config underneath you, you lose the ability to analyze against consistent data.
The test ladder is standard and worth respecting in order: unit, then string or thread, then system integration testing (SIT) in a production-like environment, then end-to-end and user acceptance testing (UAT). Where a partner system is not ready, use stubs and mocks so the flow can proceed. For payroll, parallel testing is its own gate: run the new system against legacy for several cycles and research every variance to root cause. The rule I hold is simple. If there is not enough time left to run two or three real parallel cycles, you move the go-live date, you do not shave the parallel testing. Two testing details save cutover weekends. Test at production volume, not on the small sample that passes early SIT, because an interface that clears on 200 records can still fail on 200,000. Then run a connectathon where both sides of each close-critical handshake exercise the real exchange, once each side is stable. Environments are the enabler most programs under-plan. Workday's own model is a good illustration: separate implementation tenants for testing, a weekly-refreshed sandbox, and a preview tenant that gets feature updates ahead of production, with a typical program running four to ten or more active implementation tenants.
One security role stopped testing for a week. I once watched an end-to-end testing cycle stop for a full week because one security role exposed compensation data far wider than intended. Every test script that touched pay had to pause. The build was fine. The design decision was not. Sequencing and design discipline, not raw effort, is what keeps a test cycle moving.
10. Cutover is where conversion and integrations pay off or come due
Cutover is where conversion and integrations either pay off or come due. Treat every interface at cutover as a small switch with its own plan: stop the old feed, capture and reconcile the final file, start the new feed, validate the first file with control totals, and confirm error handling and replay work. Rehearse the full cutover at least twice, once early to prove sequencing and once late to simulate the real timing and staffing, and update the runbook after each. Stand up a command center with a dedicated integration lead alongside conversion, security, and business readiness, so no interface is orphaned in the one window where orphaning is fatal.
Before the production load runs, hold a real gate. Confirm that legacy cleansing reached the agreed level, that the conversion packages all run clean, and that configuration is loaded, then make the go or no-go decision. The production conversion introduces nothing new. It is the final mock reconciliation package run one more time against production, which is exactly why the mocks had to reconcile first. Then comes the part finance feels: the first close. Converted balances have to tie out, subledgers have to reconcile to the general ledger, and auditors will re-perform reports to confirm the numbers survived the move. Do not assume your legacy reconciliations carry over unchanged, because a new finance data model can change which reconciliations even exist. In hypercare, watch interface failure rates and exception-queue aging every day, and know your rollback reality up front, because rollback is rarely a clean switch back.
One late conversion nearly took the whole go-live down. On a statewide program this year, one data conversion ran so far past its window it nearly pushed go-live and blocked the first payroll run. One workstream, and the entire timeline was suddenly at risk. That is how much these two workstreams weigh on the date.
11. Different tools, identical management job
The platforms give you different tools. However, the management job is identical: iterate the loads in dedicated environments, reconcile against control totals, and own the data yourself.
On Workday
Workday separates environments deliberately. Production is the gold copy. Sandbox is a weekly refresh of production. A preview tenant receives feature updates ahead of production so you can test integrations against the next release, and implementation tenants are on-demand replicas you spin up for configuration and third-party integration work, with a typical program running four to ten or more. For loading data, the Enterprise Interface Builder (EIB) is the no-code, spreadsheet-driven tool business users run for bulk loads. Workday Studio handles the complex, orchestrated integrations with real error handling, and Core Connectors are the configurable, Workday-maintained templates for common patterns. The tools change nothing about ownership. The EIB will load whatever you give it, correct or not.
On Oracle
Oracle Cloud runs the same play with different names. File-Based Data Import (FBDI) is the primary bulk conversion vehicle: you fill an Oracle-provided template, generate the file, and load it through interface tables into the application. ADF Desktop Integration (ADFdi) gives you live create-and-update from inside Excel for smaller volumes and correction. Oracle Integration Cloud (OIC) is Oracle's integration platform, able to transform source files into FBDI format and invoke the import job for recurring, automated interfaces. Across both platforms, conversion iterates through the test cycle, a conference room pilot (CRP) validates configuration on real data early, and UAT confirms readiness after configuration is frozen. Same discipline, different labels.
On most failed programs, the software did what it was sold to do. What broke was the data going into it and the connections coming out of it, and both broke for reasons that were decided months earlier: who owns the data, what actually converts, how many interfaces there really are, and whether testing got the time it needed.
The software was never the risk
Those are management decisions, and they are yours to make. Make them early, put a name on every one, and hold the sequence when the pressure comes. Do that and cutover is the calmest weekend of the program, because by then it is just the last mock, run one more time, on data you already trust.
Related: Data conversion: the part everyone underestimates, Testing and independent validation, and Hypercare and stabilization. See also negotiating with your System Implementer.