🗄️ OasisPro · IFS Cloud Data Migration · Go-Live Planning · UK IFS Consultants
The workstream that sinks IFS timelines.
7 rules for getting migration right.
IFS Cloud data migration is where more programmes lose time than anywhere else, and it is almost never the workstream that gets the attention at kickoff. Functional design gets workshops. Integrations get architects. Migration gets a line on the plan and whoever is free. Then the first test load runs, the reconciliation does not balance, and a quarter disappears while everyone argues about whose numbers are right.
None of this is caused by IFS Cloud data migration tooling. It is caused by treating migration as a technical task when it is a business decision-making exercise with a technical component.
These are the 7 rules that keep it under control.
Nobody has ever regretted migrating too little data. Plenty of organisations have spent months moving history they never looked at again.
The instinct in any IFS Cloud data migration is to bring everything, because leaving data behind feels like losing something. In practice, closed transactions from six years ago are read once a year at most, and often never. They can live in the legacy system or an archive. Every extra year you migrate multiplies extraction effort, transformation rules, test cycles and reconciliation work, and it adds risk to a cutover weekend that is already tight.
The 7 rules of IFS Cloud data migration
- 1. Decide what moves before you decide how. Master data, open items and balances almost always. Closed history almost never. Make that decision explicitly with finance and operations in the room, and write it down.
- 2. Cleanse in the legacy system, not in transit. Fixing data during transformation means the mess still exists in the source, so every subsequent test load reintroduces it. Fix it where it lives.
- 3. Give every data object a named business owner. Customers, suppliers, parts, BOMs, assets, open orders. Someone must be able to say which records are still real, and it cannot be the implementation partner.
- 4. Treat the first test load as diagnosis. It is not supposed to work. Its job is to produce the defect list. Planning for it to succeed is why projects only discover their problems late.
- 5. Reconcile after every load, not just the last. Record counts, financial totals, stock valuations, open order values. Reconciliation that starts at the final load is reconciliation that will not finish in time.
- 6. Rehearse the cutover with the clock running. The last test load should mirror go-live conditions and be timed end to end. If it takes eighteen hours you need to know that in advance, not on the Saturday.
- 7. Plan the archive before you switch off the legacy system. Whatever you chose not to migrate still needs to be reachable for audit, warranty and dispute. Decide the retention route early.
Finance reconciliation
Trial balance, aged debtors and creditors, and stock valuation must tie back to the legacy position on the same date. Finance sign-off is a gate, not a formality, and it needs a rehearsed process.
Operational data
Parts, bills of material, routings, assets and maintenance history carry years of accumulated inaccuracy. This is the data that quietly breaks planning and scheduling after go-live if it is not corrected first.
Cross-workstream links
IFS Cloud data migration touches permissions, reporting and integrations. Loaded data means nothing if users cannot see it, reports cannot read it, or interfaces reference identifiers that changed in transit.
Coming from Applications 10, migration is not the only thing that does not carry across
The same upgrade brings three other workstreams that surprise people. Security models do not transfer cleanly, so IFS Cloud permissions frequently need designing from scratch. Crystal Reports leaves the platform entirely at 26R2. And custom events and integrations built against older structures need reworking against OData projections. Plan all four together.
What good IFS Cloud data migration looks like on a plan
It starts in parallel with functional design rather than after it, because scope decisions about data depend on process decisions.
A controlled IFS Cloud data migration has its own workstream lead, its own reconciliation pack, and its own gate before cutover that the business can genuinely fail.
It assumes at least three loads and books environments for them in advance, because environment availability is a common hidden constraint.
The IFS Community and the IFS documentation site are useful for the technical mechanics of loading.
Our IFS Cloud upgrade guide puts migration in the context of the wider move from Applications 10.
Loaded is not migrated. Data is migrated when the business signs that it reconciles and agrees to run on it.
The five questions that size an IFS Cloud data migration
How many source systems feed the IFS Cloud data migration? One legacy ERP is a project. Four systems plus spreadsheets held by individual departments is a programme.
How many legal entities and sites? Multi-company structures multiply reconciliation work, because every entity needs its own balanced position at cutover.
How good is the master data really? Not how good people believe it is. Profile it, count the duplicates, and measure the blank mandatory fields before anyone commits to a date.
How much history does the business genuinely need in the new system, as opposed to reachable somewhere? These are different requirements with very different costs.
And who can make decisions? An IFS Cloud data migration stalls fastest when nobody has authority to declare a customer record obsolete.
Answer those five honestly and the estimate becomes defensible. Skip them and you are quoting on hope.
OasisPro run migration as a business workstream with technical muscle behind it.
Scope workshops with finance and operations, cleansing in the source system, repeatable load scripts, a reconciliation pack that ties to the legacy position, timed cutover rehearsal, and an archive plan for everything you deliberately left behind. Our consultants come from enterprise ERP delivery where a failed cutover is not survivable.
Permissions is the other workstream that overrunsFind out how big your migration really is.
We will profile your legacy data, tell you what genuinely needs to move against what can be archived, size the cleansing effort honestly, and give you a load and reconciliation plan you can put in front of your steering group with confidence.
How long does IFS Cloud data migration take?
It depends far more on data quality than on data volume. A clean single-entity dataset with a well-understood legacy system can be migrated across a few test cycles in weeks. Multi-company estates with decades of history, inconsistent part numbering and no clear owner routinely take several months, and that work runs in parallel with the rest of the programme rather than after it.
Should we migrate historical transactions into IFS Cloud?
Usually far less than people first assume. Open items, current balances and master data need to move. Closed history frequently does not, because it can be retained in the legacy system or an archive for reporting and audit. Every additional year of history multiplies extraction, transformation, testing and reconciliation effort.
How many test migrations does an IFS Cloud project need?
At least three, and four is common. The first load exists to reveal problems rather than to succeed. The second proves the fixes. The third should be a rehearsal under cutover conditions with timings recorded. Projects that plan for one load and hope invariably discover their issues in the go-live weekend.
Who should own data migration on an IFS Cloud project?
The business, with technical support rather than the reverse. Only the business can decide which customers are still active, which parts are obsolete, and which balances are real. Handing migration entirely to IT or to a partner produces a technically successful load of data nobody trusts.
Get IFS Cloud data migration right and the rest of the programme gets easier
A clean, reconciled, business-owned IFS Cloud data migration makes testing meaningful, training realistic and go-live calm.
Bad data makes every workstream around the IFS Cloud data migration look broken, because nobody can tell whether a problem is configuration, permissions or simply a record that was wrong before it moved.
Start it early, scope it ruthlessly, and give it an owner with authority.
Above all, resist the pressure to start loading before the scope decisions are made. An IFS Cloud data migration that begins with extraction rather than with decisions ends up doing both twice.