IFS Cloud ERP Implementation: Phases, Roles, Checklist

The IFS implementation method is prototype-driven: the project builds a working prototype early, confirms it against the customer's own processes, and only then builds the full solution. Customer project pages that follow the IFS method, such as the Western University EAM milestone page, list five phases: Initiate, Confirm Prototype, Establish, Implement and Go Live. A thread on the IFS community uses the same sequence and points to the IFS Academy course "IFS Implementation Methodology" for the detail. Partners relabel and subdivide the phases, so take the names as a vocabulary and confirm the exact gates in your contract.

Within those phases the work falls into the same recurring streams: solution design and configuration, data migration, integrations, reporting, testing, security, training and change management, and cutover. Data migration is covered in the IFS Cloud data migration plan, and testing in IFS Cloud testing.

The table maps each phase to the evidence that proves it is finished. The phase contents follow the IFS method as published on the milestone page above; the evidence column is my own practice, because gate evidence is not prescribed by the method.

Hypercare is not a named phase on the published milestone page; its length and scope come from the partner contract, so check what it covers before you sign.

To keep the evidence column honest, the Qualification Gate Checklists template (IDK-08) turns it into five gate checklists, each item needing evidence a third party can inspect. It is one of 24 templates grouped by the same five phases in the Implementation Docs kit.

The customer must name four roles before the prototype phase starts, because each one holds a decision the implementation partner cannot make.

• Steering committee. Approves scope changes, budget and the go/no-go. It needs an executive who can overrule a department.
• Product owner. Decides process questions between workshops. Without this person, open design questions queue until the next steering meeting.
• Key users. Run the prototype workshops, write and execute test scripts, and train colleagues. They need protected time in their calendar, not goodwill.
• Data owners. One named person per data domain (customers, suppliers, parts, prices, open orders) who approves the cleansed data before it is loaded. The partner can extract and transform data, but it cannot declare a supplier record correct.

The data side has its own role, described in the role of the IFS Cloud data migration manager. For the delivery side of the table, see IFS Cloud implementation consultants.

You need at least one environment for building and testing and one for production, and in practice a separate environment for user acceptance testing so that configuration is not changing while users test. The exact environment set, who provisions it and what it costs are defined in your IFS cloud agreement, so ask for the list with purpose, owner and refresh policy during Initiate.

After go-live the environments serve the release cycle. IFS community answers from a 2026 service webinar state that new releases can be deployed to test environments to validate them against your configuration and customisations, that each release stays supported for approximately two years from general availability, and that temporary test environments created on demand are not meant to hold customer data permanently (IFS community Q&A). The practical consequence: keep a test environment that mirrors production configuration, and read IFS Cloud upgrade readiness before your first release update.

Data migration is planned from the Confirm Prototype phase, where the migration approach is defined, and it is rehearsed repeatedly before go-live. Each migration object needs an owner, a source, a transformation rule, a load method and a reconciliation check that compares counts and values before and after the load.

Two failure patterns recur. First, load runs that succeed technically while the data is wrong, because nobody reconciled it; this is the subject of silent killers in FNDMIG and DMM. Second, cleansing left to the last weeks, because it needs business decisions that take calendar time. A practical walk-through of the tool is in IFS DMM step by step.

Testing proves that the configured system supports the processes the business agreed in the prototype, using migrated data and the real integrations. The method places solution acceptance testing in Establish and operational readiness testing in Implement. User acceptance testing is run by the key users, on scripts traced to business processes, and ends with a signed result per business area.

A tracker that shows script, owner, status, defect and retest result is the minimum record; a ready-made version is described in the UAT test tracker template, and the approach in UAT in IFS Cloud. If your project replaces Crystal Reports output, add report acceptance to the scope early: moving from Crystal Reports to Report Studio shows what has to be rebuilt and re-checked.

Permission sets are designed during Establish, from a role-to-process matrix, and they are tested in UAT with real user profiles, not with an administrator account. Access in the IFS Cloud web client is granted through permission sets that contain projections, as the IFS community thread on Aurena access permission sets describes, so a role that "works" for the consultant may expose more than intended to an ordinary user.

Write the conflicting duty pairs down (for example, creating a supplier and approving a payment to that supplier) and test them with the finance owner present. The method is in permission sets and segregation of duties; the rules a business agrees before configuration are in the enterprise book of rules.

A governance cadence is a fixed rhythm of meetings that each produce a decision list: a weekly working session between the product owner and the partner lead, a regular steering committee, and a gate review at the end of every phase. The rhythm matters more than the frequency. Decisions that need a steering committee must reach one within days, otherwise the plan slips quietly while the status stays green. The full model is in governance cadence.

Cutover is a written runbook of timed steps (freeze legacy transactions, extract, load, reconcile, switch integrations, open the system) that is rehearsed end to end with real timings: rehearse the cutover at least once before go-live, and repeat until the reconciliation results are clean. The go/no-go meeting reviews open defects, reconciliation results, user readiness and the rollback criteria, and the decision is recorded with the name of each approver.

After go-live, hypercare covers the first real business cycles. The first period-end close is the best test of whether finance, supply chain and reporting work together, so keep the project team in place until it is completed. If you want purchasing exceptions watched from the first day of hypercare without touching IFS, the SCM Automation Pack reads IFS over read-only OData, creates no objects in IFS and starts with an observation week in which nobody receives a message. Projects with several sites add a rollout sequence on top of this; see multi-site IFS Cloud implementation.

Implementations fail when decisions, data or testing time are missing, and the system itself is rarely the cause. The recurring patterns are listed below with the early signal that shows each one.

• No empowered product owner: the design-issue log grows between workshops.
• Data without owners: cleansing tasks have no named approver, and load rehearsals keep failing reconciliation.
• Key users without time: test scripts are written by the partner and executed late.
• Scope growing through gaps: each gap is accepted in a workshop and none is priced or decided at steering level.
• Security left to the end: permission sets are first tested with real users in UAT, when little time remains to change them.
• Go-live date fixed before the evidence exists: the date drives the plan instead of the gate results.

Two longer treatments are why IFS Cloud implementations fail and the brutal truth about IFS implementations.

Use this list before you sign a plan or approve a phase. Each item is answered with a document, a name or a date.

1. Scope in writing. Sites, legal entities, modules, integrations and reports, with what is explicitly out.
2. Named roles. Steering members, product owner, key users with their allocated time, and one data owner per domain.
3. Phase gates with evidence. Each gate lists the artefacts from the table in section 2.
4. Environment plan. Purpose, owner and refresh rule for every environment, including the UAT environment.
5. Migration inventory. Every object with source, owner, transformation, load method and reconciliation check.
6. Test strategy. Who writes scripts, who executes them, how defects are classified and what blocks go-live.
7. Permission matrix. Roles to permission sets to processes, with the conflicting duty pairs listed.
8. Governance calendar. Steering, working sessions and gate reviews on the calendar from day one.
9. Cutover runbook and rehearsals. Timed rehearsals, repeated until the reconciliation results are clean, before the go/no-go meeting.
10. Hypercare terms. Length, scope, response times and the named owner who takes over afterwards.
11. Release plan. How the first release update after go-live will be tested.

If you want an outside review of a plan, a vendor proposal or a project already in trouble, see services for IFS Cloud.

Book a 30-minute call

Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.

Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.