If you've been shopping around for an ERP system, you've probably heard at least one horror story. A company down the road spent months and a significant budget rolling out a new system, only to end up with staff bypassing it entirely, spreadsheets creeping back in, and a project that quietly gets labeled "the ERP thing that didn't work."

Here's what's important to understand: in the vast majority of these cases, the software wasn't the problem. Microsoft Dynamics, and most modern ERP platforms, are mature, well-tested systems used successfully by thousands of businesses across the world, including right here in Kenya. What actually derails these projects is almost always the same handful of mistakes made in the first 90 days of implementation — the window where habits, data, and trust in the new system either get built correctly or don't get built at all.

This post breaks down exactly where ERP rollouts tend to go wrong, why the first three months matter so much more than people expect, and what a properly managed implementation actually looks like.

Why the First 90 Days Matter So Much

Every ERP implementation has a honeymoon period and a reckoning period, and they usually happen in the same quarter.

In the early weeks, there's excitement. Leadership has bought in, the vendor is onsite or available, and the system is new enough that any friction gets chalked up to "just getting used to it." But by day 60 or 90, the real test arrives: staff are using the system without close supervision, the first month-end close has happened (or been attempted), and the initial data load has either held up or started showing cracks.

If the fundamentals weren't handled properly during setup, this is exactly when problems surface — and by then, the cost of fixing them is much higher than it would have been at the start. Re-training a team that's already formed bad habits is harder than training them right the first time. Cleaning up data that's been actively used and modified in the new system is harder than cleaning it before migration. This is why implementation partners talk so much about the first 90 days: it's not an arbitrary milestone, it's the period where the project's long-term trajectory gets set.

The Most Common Failure Points

Having worked with businesses across different industries on ERP rollouts, a few failure patterns show up again and again. Almost every troubled implementation traces back to one or more of these.

1. No Real Change-Management Plan for Staff

This is, by a wide margin, the most common reason ERP projects stall. A business will invest heavily in selecting the right software and configuring it correctly, then treat staff training as an afterthought — a single walkthrough session a few days before go-live, with no follow-up.

The result is predictable. Employees who don't feel confident in the new system quietly fall back on what they know: Excel, WhatsApp approvals, paper records. Within a few weeks, you have a business that technically owns an ERP system but is still functionally running on the old process, just with extra steps.

Good change management isn't just a training session. It includes:

• Identifying a project champion in each department who understands both the old process and the new system, and can answer day-to-day questions without escalating to IT
• Role-based training, not generic training — a warehouse clerk and a finance manager need to learn completely different parts of the system
• A defined "no going back" policy, so staff aren't quietly maintaining parallel spreadsheets as a safety net once the system is live

2. Trying to Migrate Everything at Once

There's a natural instinct to want to "just get it all done" — move every department, every process, and every historical record into the new system in one big-bang launch. In practice, this is one of the most reliable ways to overwhelm a team and guarantee something breaks.

A phased rollout, by contrast, lets a business validate the system with one process or department before expanding it. This is the core idea behind structured methodologies like Microsoft's Sure Step approach: implementation moves through defined stages — diagnostic, analysis, design, development, deployment — rather than assuming everything can be configured and adopted simultaneously.

A phased approach typically looks something like:

1. Start with a single core process (often finance or inventory, since most other processes depend on them)
2. Run that process in parallel with the old system for a defined period
3. Confirm the numbers reconcile and staff are comfortable
4. Expand to the next department or module
5. Repeat until full rollout is complete

It takes longer to reach full deployment this way, but it dramatically reduces the risk of a business-wide disruption, and it gives staff time to build genuine confidence in the system rather than being thrown into the deep end.

3. Sloppy Data Migration

An ERP system is only as good as the data inside it, and data migration is consistently underestimated. Businesses often assume their existing records — customer lists, inventory counts, supplier details, historical transactions — are in reasonably good shape. In reality, after years of manual entry, duplicate customer records, inconsistent product naming, and outdated supplier information are almost always present.

If this data gets migrated as-is, the new ERP system doesn't fix these problems — it just gives them a more expensive home. Inventory counts that were already wrong stay wrong. Duplicate customers keep generating duplicate invoices. And because the ERP system now presents this data with more authority and structure than the old spreadsheet did, staff are more likely to trust numbers that were never accurate to begin with.

Proper data migration involves:

• An audit of existing data before migration, not after
• A defined cleanup process for duplicates, inconsistent formatting, and missing fields
• A validation step where migrated data is checked against source records before the system goes live, not discovered to be wrong during the first reporting cycle

4. No Dedicated Internal Owner for the Project

ERP implementation is sometimes treated as something that happens to a business, delivered fully formed by a vendor, rather than something the business actively co-owns. This mindset almost guarantees problems.

Even with the best implementation partner, someone inside the business needs to own the project: someone who understands both the operational reality of the company and enough of the system's logic to make decisions during configuration, flag issues early, and hold departments accountable for adoption. Without this person, decisions get delayed, requirements get miscommunicated, and there's no one internally invested in making sure the rollout actually sticks after the vendor's active involvement winds down.

This doesn't need to be a full-time hire. In many successful implementations, it's an existing finance or operations manager who's given the time and authority to take this on for the duration of the project.

What a Properly Phased Rollout Actually Looks Like

Bringing these points together, a well-run implementation generally follows a structure like this:

Diagnostic and planning. Before any configuration begins, the implementation partner works with the business to understand current processes, pain points, and priorities. This is also when data audit and change-management planning should start — not after go-live.

Design and configuration. The system is configured to match how the business actually operates, rather than forcing the business to adapt entirely to the software's defaults. This stage should include validation checkpoints, not just a single sign-off at the end.

Pilot deployment. A single process or department goes live first, running in parallel with the existing system where practical. This is the stage where most of the "unknown unknowns" surface — and it's far cheaper to fix them here than after full rollout.

Phased expansion. Once the pilot is validated, additional departments and processes are brought online in planned stages, with training tailored to each group.

Post-go-live support. This is the stage businesses most often skip or underfund, and it's exactly the period covering those critical first 90 days. Dedicated support during this window — training reinforcement, quick issue resolution, and monitoring adoption — is what determines whether the system becomes part of how the business actually operates, or quietly gets abandoned in favor of old habits.

A Quick Readiness Checklist

Before starting (or restarting) an ERP implementation, it's worth honestly answering a few questions:

• Do we have someone internally who will own this project day-to-day, with real authority to make decisions?
• Have we actually audited our existing data, or are we assuming it's cleaner than it probably is?
• Is our rollout plan phased, with defined checkpoints, or are we planning to launch everything at once?
• Does our training plan go beyond a single onboarding session, with role-specific content and a named point of contact per department?
• Have we budgeted time and support for the 90 days after go-live, not just the weeks leading up to it?

If the honest answer to more than one of these is "no" or "not yet," that's not a reason to abandon the project — it's a reason to slow down and address it before go-live rather than after.

Getting It Right the First Time

ERP failures are rarely about choosing the wrong software. They're about underestimating how much of the work happens in the details of rollout: the training that actually sticks, the data that's actually clean, the phased approach that actually gives staff time to adapt, and the internal ownership that keeps the project accountable after the vendor's initial involvement tapers off.

At FanisiTech, our implementations follow the Microsoft Sure Step methodology specifically because it builds these safeguards into the process rather than leaving them to chance. If you're evaluating an ERP implementation — or trying to understand why a previous one didn't take — we're happy to walk through where your business stands against the checklist above.

Thinking about an ERP rollout, or trying to rescue one that's already underway? Get in touch with the FanisiTech team for a readiness review before you commit to a timeline.

Office Number: 718, 7th Floor, KU PLAZA, Haile Selassie Avenue, Nairobi CBD
Postal Address: P.O. Box 25063-00100, Nairobi, Kenya
Phone: +254 743 313 103
E-mail: info@fanisitech.com 
Website: www.fanisitech.com