🚦 OasisPro · IFS Cloud Go-Live · Cutover Planning · UK IFS Consultants
Week one problems start
three months earlier.
IFS Cloud go-live week has a familiar shape. On Monday a warehouse supervisor cannot release a work order. By Wednesday a finance user can see something they should not. By Friday somebody has discovered a report that no longer runs. None of these are software faults. They are the visible symptoms of workstreams that were picked up too late, and every one of them was preventable a month earlier.
The last 30 days before cutover are not for building. They are for proving, and for finding out what is not ready while there is still time to act.
Here are the 7 checks worth running in that window.
A go-live does not fail on the day. It fails in the decisions taken twelve weeks earlier, and the final month is simply when those decisions become visible to everybody.
This is why post-mortems so often conclude that the cutover weekend went fine and the problems started on Monday. The weekend is a technical exercise and it usually works. Monday is when real people attempt real work under real access, against real data, using real reports. Everything deferred arrives at once.
The 7 checks before an IFS Cloud go-live
- 1. Can real users complete real tasks? Not a permissions review. An actual planner, buyer and supervisor doing an actual day under their assigned access. Blocked work is the only honest signal.
- 2. Does the data reconcile, on the final load? Trial balance, aged debtors and creditors, stock valuation and open orders, tied to the legacy position on the same date, with finance signing rather than nodding.
- 3. Have integrations been tested on the target release? Bank feeds, EDI, ecommerce, payroll and compliance connections all fail quietly and are usually noticed first by a customer.
- 4. Will your reports still run? If you are moving to 26R2 or later, Crystal Reports is gone. Every operational document that depends on it needs a confirmed route before cutover, not after.
- 5. Has the cutover been rehearsed with the clock running? End to end, timed, in a non-production environment. If the sequence takes eighteen hours you need that number in advance.
- 6. Is hypercare actually staffed? Named people, still available, not reassigned to the next project the following Monday, covering at least one full period-end close.
- 7. Are rollback criteria agreed and owned? What conditions trigger reverting, who decides, and by when. Agreed in daylight, in advance, in writing.
The three workstreams that produce most week-one failures
Permissions, because access design is invisible until somebody tries to work. Data, because a single test load proves almost nothing. And reporting, because it is treated as a formatting concern until the week the invoices will not print. All three are predictable, and all three are usually scoped last.
What the final month before an IFS Cloud go-live should feel like
Calm, and slightly boring. If the last four weeks are full of building rather than proving, the date is the problem, not the team.
Defect counts should be falling, not flat. A stable defect count in the final fortnight usually means new problems are being found as fast as old ones are fixed.
Business sign-off should be a gate that can genuinely be failed, with named owners for data, access and reporting each able to say no.
The IFS Community is a useful place to compare cutover experiences, and the IFS release pages confirm what each version changes.
Our data migration guide and permissions guide cover two of the three usual culprits in depth.
Moving a go-live date is embarrassing for a fortnight. Going live unprepared is expensive for a year.
What an IFS Cloud go-live rehearsal actually involves
A rehearsal is not a test load. It is the entire cutover sequence, run in order, in a non-production environment, with the clock running and someone recording timings.
Final data extraction and load. Reconciliation of balances and counts. Access enablement for every role. Integration switchover. Smoke testing of the critical transactions.
The output is a timed runbook: how long each step took, who performed it, and what went wrong. That document is what makes the real weekend predictable.
Most teams discover their sequence is longer than assumed, and that two steps they thought were parallel are actually dependent. Far better to learn that in rehearsal.
Staffing the first weeks after an IFS Cloud go-live
Hypercare fails when the people who made the configuration decisions have already moved to the next engagement.
Keep named individuals available, publish who covers what, and give the business a single route to raise issues rather than three informal ones.
Cover at least one full month-end close before standing down. Daily transactions hide problems that period-end exposes immediately.
And triage ruthlessly in week one. A large proportion of early tickets are access questions and training gaps rather than defects, and treating them all as defects buries the genuine ones.
Deciding whether to move an IFS Cloud go-live date
The question is not whether the team is tired. It is whether the three usual failure points are genuinely proved.
Can real users complete real tasks under real access? Does the data reconcile on the final load with finance signing? Will every operational document still print?
If any answer is no with two weeks remaining, the honest options are to move the date or to reduce scope, not to hope.
An IFS Cloud go-live moved by three weeks is a scheduling inconvenience. One attempted unprepared consumes the following quarter and damages confidence in the system itself.
OasisPro run cutover the way enterprise ERP teams run it.
Timed rehearsals, reconciliation packs finance will actually sign, access tested by real users on real tasks, a confirmed reporting route including CrystalWorks where Crystal Reports must survive, and hypercare staffed by the people who made the configuration decisions.
Reporting is the check most often missedThirty days out and not certain you are ready?
We will review your access testing, reconciliation position, integration coverage, reporting route and cutover plan against what actually needs to be true before go-live, and tell you plainly which of them are not there yet.
What usually goes wrong at IFS Cloud go-live?
Access, data and reporting, in roughly that order. Users who cannot complete a task because permissions were designed late. Balances that do not reconcile because migration was signed off on a single load. And reports that no longer run because reporting was treated as a post-go-live problem. The software itself is rarely the cause.
How long should hypercare last after an IFS Cloud go-live?
Plan for at least two to four weeks with the delivery team still available rather than reassigned, and cover at least one full month-end close. The first period-end is where problems that daily transactions hide will surface, and it needs people who understand the configuration decisions that were made.
What is a cutover rehearsal and is it really necessary?
It is a timed, end-to-end run of the go-live sequence in a non-production environment: final data load, reconciliation, access enablement, integration switchover, and smoke testing. It is necessary because it is the only way to learn how long the sequence actually takes before you are committed to it.
Should an IFS Cloud go-live have rollback criteria?
Yes, and they should be agreed in advance with a named decision maker. Define what conditions would trigger reverting, who makes that call, and by when. Deciding this at two in the morning during a difficult cutover is how organisations end up living with a bad outcome because nobody felt able to stop.
A good IFS Cloud go-live is decided long before the weekend
The cutover itself is a technical sequence, and technical sequences can be rehearsed until they are reliable.
What cannot be rehearsed at the last minute is whether access, data and reporting are genuinely ready, because each of those is weeks of work if the answer is no.
Run the 7 checks early enough that the answer still matters.
One more habit worth adopting. Write the go-live decision criteria down at the start of the project, not at the end, when everyone is invested in the date.
A criterion agreed in month two is a genuine gate. The same criterion invented in the final fortnight is a negotiation, and it usually resolves in favour of proceeding.