Building Your Own Team for an IFS Cloud Upgrade? Good. Just Don't Do It Alone.

The software going live was never the hard part. Whether your team can run it afterward is.

An email I received recently stuck with me. It was about companies building internal teams. Hiring analysts, administrators, functional leads. Choosing to own the move instead of handing it entirely to a partner and hoping for the best.

My first reaction was simple. Good. That is exactly the right instinct.

Owning your ERP is the goal

The companies that thrive on IFS aren't the ones with the biggest implementations. They're the ones whose own people understand the system well enough to run it, guide the business, change it, and defend it.

An implementation partner builds the software. That is their job, and the good ones do it well. But when the project ends and the consultants roll off, the system becomes yours. Every process question, every configuration decision, every new release lands on your team. If that team can't carry it, you haven't bought independence. You've bought a standing dependency on outside help that never ends.

So building an internal team isn't a cost to minimize. It's how you invest the money well.

The trap is building the team during the upgrade

Here's the part that worries me.

Building that team at the same time you're running the upgrade is like learning to fly while the plane is taking off. Apps-to-Cloud isn't a patch. It's a re-platform, new data model, new architecture, genuine change management. Your internal team is at its weakest precisely when the technical risk is highest, because they're learning the new system and delivering it in the same breath.

The software will go live either way. The vendor and the integrator will see to that. Whether your team can actually run it the morning after is a separate question, and it's the one that decides whether the whole investment pays off.

Why this is landing now

Standard support for IFS Applications 10 ended in March 2025. What remains is extended support, and it's a stopgap by design, at rising cost. The surcharge climbs each year the window stays open. To hold onto extended support past March 2027, IFS expects customers to show an active, credible Cloud migration plan already in motion. Extended support ends outright in March 2028.

Read plainly, the organizations acting now aren't early. They're on time. The ones building teams today are the ones who did the math.

What goes wrong most often

Across enough of these transitions, the failure modes rhyme.

Treating go-live as the finish line. Go-live is the starting line. Adoption, the part where the business actually changes how it works, happens after, and it's where most of the value is won or lost.

Letting the real knowledge live in one or two heads. This is the swivel-chair tax. The productivity drain that shows up when every question routes through the same one or two people. It feels fine until one of them is on vacation or leaves for good.

Building the team from vendor slideware. Training on a demo environment teaches your people a system that isn't theirs. Real capability is built on your configuration, your data, your processes.

Letting customizations pile up. Every customization is a promise to maintain something forever. Two years on, nobody remembers why half of them exist, and standard functionality would have done the job.

None of this means don't build the team. It means don't build it alone.

What actually works

Keep senior expertise alongside your people while the team finds its feet. Not a parallel delivery crew that owns the work and hands you a solution at the end. A partner that guardrails the upgrade, transfers real knowledge into your people as it goes, and documents how your system actually works so that knowledge stays with you.

Enough support to de-risk the move and build capability. Not so much that you trade one dependency for another. The goal is a team that needs you less over time, not more. You're building something that stays, not renting a crutch.

That's the whole idea behind how we work at CLER Solutions. An extension of your team for the parts that fall outside their bandwidth, while they grow into the rest. Your people own what they need to own. We cover the gap, and we make ourselves less necessary on purpose.

The honest version

Not every company is ready for this, and that's fine. If you're early, or the budget isn't there to do it properly, we'll say so and point you somewhere that fits better. Enablement done halfway isn't enablement.

But if you're staffing up for a Cloud upgrade and thinking hard about the team side, that's exactly the conversation worth having. It's the part nobody puts on the project plan, and the part that decides the whole thing.

If that's where you are, let's talk. A short discovery conversation, no pitch, just a read on where your team is and what would actually help.

Charlie Shephard is the founder of CLER Solutions, where he helps organizations build the internal teams that own their IFS Cloud environments. After 22 years in the Marine Corps and a decade delivering IFS, he writes about the people side of ERP, the part that usually gets left off the project plan.