How to Choose an IFS Cloud Implementation Partner

A proposal sells three things that look like one: the people who do the work, the method they follow, and the support that continues after the project team leaves. Each is priced in a different part of the document, which is why total prices compare so badly between offers.

Why the named team predicts more than the brand

IFS Cloud is delivered by individuals: the solution architect who decides where a requirement is solved, the functional lead who configures finance or supply chain, the data lead who owns mapping and migration trials. The brand on the cover sets the template of the proposal; the individuals decide whether your order-to-cash scenario is walked through end to end before go-live. A proposal that lists roles without names leaves staffing to the moment after signature, when the partner’s availability, not your requirements, drives who arrives.

Ask to interview the named architect and one functional lead before signing. A partner that has not yet secured those people will offer substitutes or push the interviews past signature.

This practice sorts the market into three types, a working classification and not an official one.

• Full-scope integrator - runs the whole programme across modules, data, integrations, testing and cutover. Suits multi-site rollouts that want one accountable party. Probe for thin staffing on your modules behind a strong programme office.
• Module or industry specialist - goes deep on a domain such as manufacturing or field service. Suits a scope where process knowledge decides the design. Probe for the boundary with modules the specialist does not cover.
• Supporting-technology provider - brings integration, reporting, test automation, migration tooling or independent quality assurance around a core delivery. Suits a hybrid model. Probe for accountability when a defect sits between two vendors.

A prepared partner answers with a named person, a dated plan or a document. Compare the written answers side by side.

Team: who exactly, with which credentials, for how long

• Q1. Who are the named architect, functional leads and data lead, and what share of their time is allocated to this project in each month?
• Q2. Which IFS Cloud credentials does each of them hold today, with issue date and product version?
• Q3. What happens if a named person leaves or moves to another client: handover period, and who pays for it?

Method: testing, data migration and cutover

• Q4. How many migration trial loads are planned, on which dates, and what reconciliation evidence closes each? A single “migration” line with no trial count has no dated milestone to miss, so slippage stays invisible until cutover.
• Q5. Who writes the test scenarios, and are they cross-module business scenarios (a purchase order through receipt to supplier invoice) or a script count per screen?
• Q6. How many full cutover rehearsals are planned, as dated events with a go/no-go decision after each? The testing method behind this is described in IFS testing.
• Q7. Which testing and data validation work must our people do, in hours per week per role, and from which month?

Design philosophy: where custom logic is allowed to live

This group predicts what you pay in release updates for years after go-live. Ask the partner to place each requirement on the ladder from standard use, through the Extensibility Framework, to code in the Layered Application Architecture customer layer. The guide to IFS Cloud tailoring defines the ladder.

• Q8. For our five most customisation-looking requirements, which tailoring level will you use, and what shows that a lower level cannot solve each one?
• Q9. Who regression-tests your custom objects when a release update arrives, and is that effort inside the support fee or billed per release? Release rhythm is covered in the update calendar article.
• Q10. How is each extension documented so that someone outside your team can find, understand and retest it? Ask for a sample with customer details removed.

This practice’s reference figure is that a change set which stays additive needs up to 60% less regression testing at the next release than one carrying code in the customer layer. Further reading: strategic IFS Cloud customization and why ERP upgrades fail.

Evidence: references in your situation that you may call

• Q11. Which two reference customers run IFS Cloud with a scope close to ours (industry, modules, sites, languages), and may we call them without your staff present?
• Q12. Describe a project that went off plan: which signal appeared first, what did you change, and what did the customer decide?

After go-live: support, hypercare and knowledge transfer

• Q13. What is the hypercare model: who triages, which severity levels exist, and which measurable exit criteria end it? Detail is in the hypercare article.
• Q14. Which deliverables make up knowledge transfer (configuration documentation, process maps, administrator training), and what must our team be able to do alone on the day the project team leaves?
• Q15. What is the support model after hypercare: first contact, response times by severity, and who pays when a release update breaks a custom object?

Each pattern below is visible in the proposal before any reference call, and each has a predictable consequence a few months into delivery.

• Price without testing and migration scope - trial loads, reconciliation, test scenarios and rehearsals left unlisted return as change requests, priced when you have no alternative supplier.
• “Everything in standard” with no gap list - a fit-gap analysis that finds no gaps was not run against your processes, and the gaps surface in user acceptance testing, where each costs most.
• No statement on custom code - without a stated tailoring approach the default is whatever is fastest for the developer that day, and the regression bill arrives with the first release updates.
• No priced hypercare model - the first weeks after go-live are then staffed from whoever is left on the account.

For a running project that already shows several of these, see eight signals and a two-week health check on whether the gap sits with the vendor or the project design.

Acceptance criteria written as business scenarios

Acceptance defined as “configuration delivered” is met the day the partner says so. Acceptance defined as named scenarios, such as a customer order through delivery and invoicing with specified test data and a signed result from the business owner, is met only when the process works. Tie milestone payments to that list.

A key-person clause

List the named architect and leads with their allocation, the notice period, your right to approve a replacement, and who pays for the handover. With the clause in place, the answer to Q3 is enforceable.

Change control that prices before it executes

Require every scope change to be estimated and approved in writing before work starts, with the effect on date and cost stated. Add a rule for classifying fit-gap items found after signature as clarification of the original scope or as change, because that classification is where disputes begin.

With a shortlist and contract drafts in hand, the next step is putting each offer into comparable rows. Reading an IFS Cloud implementation quote line by line covers that exercise, and the true cost of customization in IFS Cloud covers the cost of the extensions you add.

A customer-led implementation, in which your team holds the plan and buys partner capacity for selected work packages, is viable when you employ people who have taken a project through an IFS Cloud go-live and a project manager has dedicated time. When the internal team also runs the business at full load, test execution and data cleansing slip first, and only your people can do them.

A hybrid splits accountability defensibly when the boundary follows a deliverable: a partner owns configuration of finance and supply chain while a second party owns integration, or an independent reviewer examines design and test coverage before each phase gate. Write the interface between suppliers into both contracts, including who triages a defect that could belong to either.

The weights are a starting template, not a method. Fix them before the proposals arrive, so they cannot be tuned afterwards to favour a preferred supplier. Each panel member scores alone first, from 1 to 5 per criterion; the criteria with the widest spread between scorers are where the reference calls should go.

This practice also delivers IFS Cloud implementation and support work, so it can compete with the partners on your shortlist. The second opinion offered here is therefore narrow: a review of the shortlist criteria, the proposals or the statement of work, with a list of gaps and vendor questions as the output. It does not recommend a supplier, and this article names no partner.

A review pays off before the RFP is issued, when these questions can still be built into it, and before signature, when the acceptance, key-person and change-control wording can still be negotiated. The ERP ROI analysis covers the business case that precedes both.

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.

Selected clients: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.

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