You bring an at-risk IFS programme back under control by establishing the facts first, and only then deciding on scope, planning and go-live. Eqeep reviews at-risk IFS programmes to establish the facts, priorities and decisions needed for recovery. Your leadership team keeps control of scope, responsibilities and go-live.
Scope gaps, unresolved decisions, data problems and sequencing can reinforce each other. We examine how those issues affect the plan and operational readiness.
What does the review look at?
Eqeep examines solution quality, governance, planning, integrations, data, testing and business readiness. We assess which risks affect operational continuity and the critical path.
We separate urgent stabilisation work from improvements that can wait. The proposed recovery agenda identifies priorities, dependencies, available capacity and the decisions your team needs to make.
What facts do you need before you decide?
You need evidence on six things, from the agreed scope to the capacity you really have. A percentage complete says little while the key tests are still to come. Ask your programme manager and the current partner to supply this evidence before the review starts.
- The agreed scope. What was approved, and what has been added since? In IFS’s methodology, the scope is approved after the prototype, and the prototype is locked as a reference for the rest of the project.
- Open decisions. Which design choices are waiting for a decision, from whom and since when? While a choice stays open, that part of the configuration cannot be finished.
- Test results. Which complete processes have been tested with migrated data and real user roles? That is how IFS describes the Solution Acceptance Test. Tests with sample data and full access tell you less.
- The trend in findings. How many new findings come in each week, and how many are closed? If the list is not getting shorter, the go-live date has no basis.
- Data readiness. How often has the migration been trial-run, and which records still fail? In IFS’s methodology, the data is migrated several times before the cutover is rehearsed.
- Capacity. How much time do key users and process owners really have for the programme?
If any of this evidence is missing, that is a finding in itself. For how IFS describes the checks before go-live, see IFS implementation in four steps.
How do you separate stabilisation from improvement?
Stabilise first whatever directly affects operations or a credible go-live. Everything else goes into a prioritised backlog, with an owner for each item.
Mid-implementation, that means the work on the critical path, such as data migration, integrations and the acceptance test. Requests added since the design was signed off wait until after go-live. If your leadership team still wants one in, it comes with a new plan.
If IFS is already live, stabilisation starts with the work people avoid or duplicate outside IFS. That usually shows whether the issue is process design, data, training or missing ownership.
Your leadership team sets the line between stabilisation and improvement. That line also fixes how much capacity is left for improvements.
Which decisions can reset the programme?
Typical recovery work
- Reset scope and decision rights
- Strengthen design authority and governance
- Rebuild testing, data or integration plans
- Change deployment sequence or go-live timing
Your leadership team decides which changes to make and who owns them. The plan may require a narrower scope, revised testing or a different deployment sequence. If readiness is insufficient, postponing go-live may be the responsible choice.
A narrower scope. You go live with the core processes first and move the rest to a later phase. Then also decide how the deferred work runs in the meantime, and who is responsible for it.
A phased rollout. In a blog post of 18 May 2026, IFS describes how plastics processor All American Poly went live first with finance, sales and production. Planning and quality management followed over the next year. Another IFS customer chose a big bang, and says running old and new systems in parallel is very complex.
A later go-live. Postponing only helps if the recovery plan also tackles the cause of the delay. Without that, a new date is a wish.
As an IFS Specialized Partner in the Benelux, Eqeep agrees the assessment and any recovery work with your team. We define specialist roles and workstream responsibilities before delivery starts. A focused review may be enough when the issue sits within one workstream.
What does delay mean for your IFS support?
If you have bought IFS Cloud and are moving from IFS Applications 10, Extended Support runs until 27 March 2027, or until an earlier go-live. If you are not live by then, it continues only with a demonstrable, active upgrade and migration plan, until 27 March 2028 at the latest. For a move from IFS Field Service Management 6, the same rules apply with 31 January 2028 and 31 January 2029 at the latest. IFS sets this out in its Extended Support Terms (February 2026 version).
A current recovery plan with milestones and owners helps demonstrate that migration plan. The terms that apply to you are in your own agreement with IFS. During Extended Support, IFS delivers no new legal, statutory or localisation functionality and only works on a resolution for severity 1 and 2 cases. See what that means for the move from IFS Applications 10 to IFS Cloud.
If you are implementing IFS Cloud, the release you build on ages while the programme runs. Under its support policy of February 2026, IFS supports each release for 24 months from general availability. The recovery plan should therefore state which release you will go live on, and whether a release update is needed first.
How do you involve the current implementation partner?
Involve the current partner from the first day of the review. That partner knows the configuration, the open issues and the reasons behind earlier choices. Ask for access to the environments, the approved design, the configuration and integration documentation, the test results and the open-issues list.
If you change partner, agree which documents, test results and knowledge are handed over. After go-live, access, documentation and agreements decide whether another partner can take over support. Changing support partner alone need not mean reimplementation. Discuss contractual or legal questions about your current partner with your own lawyer.
IFS project rescue questions
When does an IFS programme need project rescue support?
Seek a review when repeated milestone changes, unresolved designs or weak testing leave the plan uncertain. Unstable integrations, poor data readiness and declining stakeholder confidence also need attention. Eqeep assesses the evidence and dependencies before recommending recovery priorities.
Does project rescue mean replacing the existing implementation team?
Not necessarily. Eqeep assesses whether clearer decision rights, specialist support or a revised plan would address the issues. Your leadership team decides how responsibilities should change, retaining useful project knowledge.
Should we postpone go-live?
Postpone go-live only with a plan that shows what must be done before the new date, and by whom. Also decide which release you will go live on at that date. If you are moving from IFS Applications 10, check the new date against 27 March 2027 as well. Your leadership team decides.
Can project rescue help when IFS is already live?
Yes. In the months after go-live, workarounds creep back in and processes drift from the design. Process Intelligence shows from your IFS data how processes actually run, next to the designed flow. A value check puts the original business case next to how IFS is used today and turns the gap into a prioritised backlog.
Tell us where you stand with IFS, which milestones have moved and which decisions are open. You get one conversation and a clear next step. Discuss your IFS question.
New articles appear in our newsletter. Subscribe to the newsletter.
