WHY THIS PAPER EXISTS?

Most Infor on-prem to CloudSuite migrations don't run late because the software is hard. They run late because every phase — discovery, design, build, test, train, go-live, support — is still done the same way it was done fifteen years ago. The cloud changed. The way we deliver the cloud didn't.

The numbers back this up. The 2024 Panorama ERP Report shows the median ERP project now runs 15.5 months, and resource constraints are the single biggest cause of timeline overruns — cited by 47% of late projects, up sharply from 38% the year before. McKinsey's research is even blunter: 70% of digital transformation efforts fail to deliver, and most of those failures trace back to people and process, not technology.

THE SHORT VERSION

Here is the whole argument in five lines.

• Cloud migrations slip on people-time, not technology. The system is fine. The hours are the problem.
• Five phases eat the calendar. Requirements, configuration, testing, training, and post-go-live support — each one done by hand, each one taking longer than it should.
• AI changes the maths in every single phase. Not by replacing your team. By doing the slow, repetitive parts in days instead of months. Requirements get read in days. Tests get generated and self-heal. Training gets produced from the configured system. Support starts day one with full project memory.
• The savings stack. Save weeks in requirements, you also save weeks in everything downstream — because every later phase feeds off the one before.
• Half the calendar is realistic. Not on every task. But on the heavy ones, yes — and we are seeing it now.

PART 1 - WHERE THE TIME ACTUALLY GOES

Before talking about how to go faster, it helps to be honest about where the months disappear. From what we see across mid-market manufacturers moving to Infor CloudSuite, five things eat the calendar.

1. Requirements take 3 to 5 months — and most of it is reading

Everybody blames the discovery workshops. The workshops are fine. They are not the problem. You still need them. People in a room talking about how the business actually runs is irreplaceable.

The problem is what happens after the workshop.

Once discovery is done, your SI has a mountain of stuff to read. Meeting transcripts. Notes. Old functional specs in Word. Process maps in Visio. Pricing rules in Excel. Training slides in PowerPoint. Screenshots in PDFs. And — the hardest part — years of customisations sitting in code.

That last bit is where months disappear. To understand what a business has changed in their on-prem system, you need someone who can read Java, who also knows Infor, who has enough years on the clock to spot why a change was made and not just what was changed. Those people are rare. They are expensive. And they have ten other things on their plate.

So the work gets done in slices. A bit here, a bit there. The requirements document grows slowly. Three months pass. Sometimes five. Nobody is doing anything wrong — there is just too much to read, and not enough of the right people to read it.

2. Configuration is done one screen at a time, by hand

CloudSuite has opinions. It has templates. It has a recommended way of doing things. But on most programmes, senior consultants still configure it screen by screen, decision by decision, in their head.

The decisions get made. They just don't get written down anywhere useful. Six months later, when someone asks "why did we set it up this way?", nobody remembers.

3. Testing is the single biggest time sink — and both options hurt

Testing is where the calendar really bleeds. There are two paths most programmes take. Both cost more than people realise.

Path A — Manual testing

A small team of business analysts writes test cases from scratch, by reading the requirements document. That takes weeks. Then they run those tests by hand, find issues, raise tickets, retest. That takes more weeks. On a typical programme, the test phase is three to four months.

Path B — Automated testing (built by humans)

This is supposed to be the answer. It isn't — not the way it's being done today. The numbers from the QA industry are sobering:

Here is why. To build automated tests, you need automation engineers writing scripts. Each script is tied to specific buttons, fields, and screens. It's expensive to build upfront — typically $40,000 to $100,000 for a starter suite, plus a senior QA engineer at $140,000 per year. That's the easy part.

The hard part is what happens next. Cloud ERPs change. That's the point of cloud. Infor CloudSuite has bi-annual major releases in April and October that bring new features, enhancements, and UI changes. Monthly maintenance updates land in between. Every time the underlying system shifts, the hand-written scripts break. Buttons move. Field names change. Selectors that pointed to one thing now point to another.

Your automation team — manual programmers, however skilled — now spend their week fixing scripts instead of testing. The medium-term picture is clear: ARDURA Consulting estimates 15–25% of initial automation effort goes back into maintenance every year. For larger enterprises, it's 30–50%. Most teams quietly give up halfway through and go back to manual.

So you pay twice. Once to build automation that breaks. And once more for the manual testing you end up doing anyway.

4. Training is a tick-box exercise, not proof anyone can do the job

This is the most under-estimated risk in any cloud migration. And it is the one senior management almost never asks about.

Your users know the on-prem system. They have used it for years. They are confident. That confidence is the trap. Because the cloud interface is different. The screens look different. The clicks are in different places. The workflow is different.

Your users aren't learning. They are unlearning. And unlearning is much harder than learning. The muscle memory has to go before the new way can stick.

Yet the standard training model is: SME records a session, key users watch it, key users train end users, everyone signs the attendance sheet, training is marked complete. Nobody knows whether anyone can actually do their job on day one. You find out at 8am on go-live morning, when the warehouse can't process a goods receipt and the phones start ringing.

5. Hypercare ends, and the knowledge walks out the door

Cutover day is not when the project team disappears. They run hypercare — typically two to four weeks of intense support — and gradually hand over to the internal support team during that window. That bit works. The problem is what happens at the end of hypercare.

Once hypercare closes, the senior SI consultants who knew everything rotate onto the next client. The project documents go into a SharePoint folder. The internal support team — who joined late in the cycle and weren't in the room for most of the design decisions — are left to pick up tickets on their own.

And from that point on, every "why did we set it up this way?" question becomes a small archaeology dig. People rummage through old emails. They guess. They call ex-consultants. Months later, a small change request becomes a mini-project, because nobody really knows what touching it will break.

Deloitte's research on post-go-live points to exactly this:

This cost rarely appears in the business case. But it is real, and it lasts for years.

PART 2 - WHAT CHANGES WHEN AI SITS ACROSS EVERY PHASE

None of this is theoretical. We are watching it happen right now on a live programme — a North American outdoor brand moving to Infor CloudSuite with Wipro. Here is what each phase looks like when you stop doing things the old way.

Phase 1 — Requirements: from months to weeks

The discovery workshops still happen. People still sit in rooms. That part doesn't change, and shouldn't.

What changes is everything after the workshop. Every input the SI would normally have to read by hand goes into a requirements agent: the meeting transcripts, the Word documents, the Excel pricing rules, the PowerPoint training decks, the PDFs, the Visio process maps, the screenshots — and yes, the customised code from the on-prem system.

The agent reads it all. It reverse-engineers what the business changed in their on-prem build. It surfaces decisions that were never written down but are sitting in code. It flags contradictions between what people said in workshops and what the system actually does. It produces structured, traceable requirements — not a Word document that grows in the dark.

On the live Wipro programme, this phase is on track to be cut by more than half.

Phase 2 — Configuration: mapped, not freestyled

Once requirements are structured, configuration stops being an art form. Each requirement maps to a CloudSuite setting. Decisions are previewed before they go live. There is an approval gate. There is an audit trail — so in month 13, when someone asks why it was set up this way, the answer is one click away.

Senior consultants still apply judgement. But on the 10% of decisions that need it. Not the 90% that don't.

Phase 3 — Testing: the biggest single win

This is where most of the saved months come from. Three things change.

Test scenarios are generated from requirements, not written by hand

Every requirement produces its own test scenarios — positive cases, negative cases, edge cases. With one click. If the client already has a test pack from their on-prem system, drop it in: the agent takes those tests, adapts them to the CloudSuite UI, and fills in the gaps — including patterns this client missed, and patterns the industry typically misses.

Coverage gaps are visible from week one

Because every test is linked to a requirement, you can see what isn't covered. No more discovering at UAT that nobody tested the multi-warehouse transfer scenario.

Automation without automation engineers — and without the maintenance bill

Test scenarios get automated with one click. No automation tester needed. No scripts to maintain by hand. When the CloudSuite UI changes — which it will, every April and every October — the tests heal themselves, because the system has learned what "the same button" means even if the screen has been redesigned.

Industry data on self-healing automation shows it cuts maintenance work by 30 to 50%. That's the difference between automation that costs a fortune to maintain and automation that just runs.

Phase 4 — Training: proof, not paperwork

This is where the cloud migration playbook needs to change the most — and where senior management can have the biggest impact, just by asking better questions.

Training videos generated with one click

Walkthroughs of the actual configured cloud environment become training videos. Narrated. Multilingual. Role-specific. You don't need the SME's calendar for six weeks. You don't need a video production budget. The bottleneck of "we'll do training when config is stable" disappears.

A driver's licence for the system

Before go-live, every end user practises the exact tasks they will do on day one. Not by watching a video and clicking "I understand". By actually doing the task, in a safe environment, scored, repeatedly, until they can do it without prompts.

And — this is the part senior management cares about — you get a dashboard. By user. Who has practised. Who has passed. Who hasn't started. Who is failing repeatedly. No more ambiguous "training is 90% complete". You can see, before go-live, exactly which users are ready and which aren't.

Figure 1 — Group-level readiness dashboard. By group, by assessment, in real time.

Figure 2 — Per-user assessment results. Score, attempts, ready / not ready — at the individual level.

Phase 5 — Post-go-live: the knowledge stays

When the SI demobilises, nothing walks out the door. Every requirement, every configuration decision, every test result, every training assessment — it all lives in a system that can answer questions in plain English.

Two practical things change.

• End users get help on the screen they are stuck on. Not a generic FAQ. Not a ticket queue. An assistant inside Infor that knows what screen they are on, what they are trying to do, and how this client configured it.
• Your internal support team inherits institutional memory. They can ask "why did we set it up this way?" and get a traceable answer — not rummage through old emails.

PART 3 - QUESTIONS TO ASK BEFORE YOU SIGN THE SOW

If you are about to commit to an Infor cloud migration, these are the questions to put in front of your SI — and your own programme team. They are deliberately direct. The answers will tell you whether you are about to start a 9-month programme or an 18-month one.

On requirements

• How will you read the existing customisation code, not just the documents?
• How will you make sure you don't need to wait three weeks every time we need a senior Java-plus-Infor person to review something?
• How will every requirement be traceable to what built it, what tests it, and what trained for it?

On testing

• Are test cases written by hand from the requirements document, or generated from structured requirements?
• If you propose test automation, who maintains the scripts when the CloudSuite UI changes every April and October? How much does that cost in year two?
• Industry data shows 40% of automation budgets go to maintenance — how are you avoiding that?
• Can you show me, in week one of testing, which requirements are not yet covered?

On training

• How will I see — by user — who has actually practised their day-one tasks enough to do them without help?
• How long does it take to produce the training material once configuration is stable?
• What happens to training material when configuration changes — does it regenerate, or does someone re-record everything?

On post-go-live

• On the day you demobilise, what survives — a folder of documents, or a system my support team can query?
• How does an end user get help on the screen they are stuck on, without raising a ticket?
• Six months after go-live, can a support engineer find out why a particular setting was chosen — in minutes, not days?

PART 4 - WHAT "HALF THE TIME" ACTUALLY MEANS

"Half the time" is not a marketing line spread evenly across the programme. It is uneven. Some phases compress a lot. Some compress modestly. Some don't compress at all. Here is a realistic breakdown.

Where this doesn't apply

Three things will not compress, no matter what anyone tells you.

• Change management. People still need to be brought along. Communications, sponsorship, role changes — these are human problems and they move at human speed. Deloitte found that 82% of organisations face resistance to ERP changes due to inadequate communication, and no AI agent fixes that for you.
• Judgement calls on trade-offs. When two valid configurations exist and the business has to choose, you still need senior people and process owners in a room.
• Bad data. If your master data is messy on-prem, it will be messy on cloud. No agent can clean what the business hasn't decided.

CLOSING

The case for moving from Infor on-prem to CloudSuite is well understood. The case for moving in half the time is less about technology and more about willingness — willingness to retire the parts of the old way that are slow because they are manual, not because they need to be.

The clients who get this right finish in 9 months what their peers finish in 18. They go live with users who can actually do their jobs. With decisions you can trace. With a knowledge base that keeps working after the SI has gone.

The clients who don't, finish late, hypercare longer, and pay twice — once for the implementation, and again for the post-go-live archaeology. The Panorama numbers tell that story year after year: ERP projects routinely exceed budgets by three to four times, and 50% fail on their first attempt. The technology is not the cause. The way the work is done is.

That technology to do this differently exists today. The reason most programmes still run the old way is not feasibility. It is habit. The CIOs who break the habit first get a faster, cleaner, more durable cloud foundation — and they get it before their competitors do.

Jerome Josephraj is CEO and Co-Founder of Infomind, an AI-native ERP implementation platform working with mid-market manufacturers on Infor CloudSuite and QAD. Connect on LinkedIn or visit infomind.ai.

Sources

Panorama Consulting Group — The 2024 ERP Report (median project duration, resource constraint trends, budget overruns)

Gartner — Enterprise Resource Planning insights; Top Trends Shaping the Future of Cloud (2025); ERP implementation failure factors

McKinsey & Company — Digital transformation success rates; software adoption ROI research

Deloitte — Maintaining momentum post-go-live; Manage change with digital adoption platforms

TestGuild — Why enterprise test automation is broken (2025); QA maintenance and flaky test data

ARDURA Consulting — Test Automation Cost Breakdown (2026)

Infor — CloudSuite April and October bi-annual release announcements