Data migration is the biggest swing in most IBM i implementation quotes because nobody can price it with confidence until someone has actually looked at the data. Volume matters less than people expect. Age, quality, and the number of systems being merged matter a lot more.
That uncertainty is what you're really paying for. A systems integrator who hasn't seen your files has to price the risk of what might be in them, and that shows up as a wide range or a fat contingency line. On IBM i the usual suspects aren't exotic. Files defined in DDS decades ago rarely had referential constraints added, so the application enforced the relationships, and every program that skipped a check left orphan records behind. Dates stored as numeric fields in YYMMDD or CYYMMDD formats. Packed decimal fields. Multi-member files. Character data that needs careful CCSID handling the moment it leaves the platform.
None of that is a reason to panic. It's a reason to look before the quote instead of during the project, because a known problem gets priced as work and an unknown one gets priced as risk.
- Users
- About 120
- Footprint
- Production plus test LPAR
- Trigger
- New ERP package
- Data
- 22 years of orders and masters
Sound familiar?
Finance wants every year of history. The warehouse wants the item master cleaned up first. The implementation partner quoted migration as a wide range with a note about data quality, and nobody can say which end of it you'll land on.
What's really driving the number
The cost isn't the gigabytes. It's the validation. Every record you move has to be mapped, cleaned, loaded, and reconciled, and old records are the messiest ones: item numbers nobody sells anymore, the same customer entered three different ways, open orders from years ago that were never closed. Moving everything means paying to fix everything.
What takes the pressure off
- Set a cutoff by data type instead of one rule for everything. Active masters, open transactions, and a defined window of closed history are a very different job than the whole database.
- Run a profiling pass before the quote is final. Counts of duplicates, orphan records, and blank required fields turn a vague data quality warning into a number.
- Give each data domain a business owner who approves the cleanup rules. IT can move the data, but IT shouldn't be deciding which customer record wins.
- Decide how you'll answer old-history questions after go-live, such as a read-only copy or an archive, and price that option honestly. A retired system kept running still carries licensing and maintenance.
If this is youYou're not deciding how much data to move. You're deciding how much data you want to pay to validate. That's a business call, and it's one of the few in this project you fully control.
- Users
- About 200 combined
- Target
- 1 IBM i system
- Trigger
- Acquisition
- Sources
- 2 ERPs, 2 numbering schemes
Sound familiar?
The deal closed, leadership wants one system by a date that was set before anyone looked at the data, and the migration estimate came back higher than the software. It feels like the partner is padding the job.
What's really driving the number
Consolidating systems multiplies mapping work far more than it multiplies volume. Two charts of accounts, two item numbering schemes, two units of measure for the same part, and customers who buy from both companies. Most of that isn't technical work at all. It's decisions nobody has made yet, and a partner has to price the time it takes to chase them.
What takes the pressure off
- Run master data decisions as their own business workstream, with a deadline ahead of technical mapping: whose item numbers win, how the charts of accounts map, and how duplicate customers get merged.
- Bring open transactions and balances over from the acquired system rather than full history, and keep its history reachable separately for a defined period.
- Plan for more than one trial conversion, with a reconciliation sign-off each time. The first run finds the problems. The second one tells you they're fixed.
If this is youIf the migration quote feels high, it's probably pricing decisions you haven't made yet. Make them first, and the partner has a lot less uncertainty to charge you for.
- Users
- 500+
- Footprint
- Multiple LPARs
- Trigger
- Platform replacement
- Timeline
- 12-24 months, typical
Sound familiar?
The decision to leave the platform has been made, or it's close. The migration workstream is the part everyone is quietly nervous about, because decades of the business run through files that most of the current team didn't design.
What's really driving the number
Getting data out of Db2 for i is the easy part. SQL will read almost anything on the box. The cost is in transformation: numeric dates, packed decimals, and character data that has to convert correctly out of EBCDIC. The bigger trap is data that doesn't exist as data at all. RPG programs often calculate prices, statuses, and balances at run time, so the value a user sees on screen was never stored in a file. Nobody can migrate what was never written down.
What takes the pressure off
- Before mapping starts, list the screen values users rely on that are calculated in programs rather than stored, and decide how the new system will produce each one.
- Check CCSID tagging on source files early. Files tagged 65535 or holding mixed data need explicit handling, and finding that in week one is far cheaper than finding it in a mock cutover.
- Budget reconciliation as its own line, not as part of the load. Proving the numbers match is the work that lets finance sign off.
- Pressure-test the business case. Published benchmarks suggest a move off IBM i tends to pay for itself only when current annual maintenance and support already runs past roughly $300,000.
If this is youThe data leaving the box is rarely the problem. The logic that never lived in the data is. Find it first, and the rest of the migration gets a lot more predictable.
These scenarios are composites built from common IBM i project patterns and the published ranges on this site, not individual client case studies. Use them to recognize your situation, then get a scoped proposal against your own data.
A partner who gets that list can price work instead of risk. That's usually where a wide range starts to narrow.