Getting Your Municipal ERP Replacement Right

October 26, 2026

Most ERP projects that struggle don't failbecause of the software. They struggle because of people, ownership andpreparation, and nearly every one of those problems can be prevented.

I've worked on both sides of the table.I've been the municipal employee living with a system that was chosen before Iarrived, and I've been the vendor trying to make projects work for a client whowasn't set up to succeed. From both seats, I've watched the same handful ofissues come up again and again.

At Perry Group, we decided to find out ifthe marketplace had a similar experience. We interviewed 11 different vendorsand implementers working in the municipal ERP space. We asked them whatseparates the projects that go well from the ones that struggle, and theirinsights became our 21 Municipal ERP Success Factors, which you can alsodownload with this article. We kept those interviews anonymous so people couldgive us their honest feedback, and you'll see some of what they told us quotedthroughout. Each section below notes which success factors it covers, so youcan dig deeper into the companion document. Any project can be overwhelming, especially an ERP. Remember, you don'tneed to tackle everything at once. Read it, find the two or three areas whereyour organization is most exposed, and start there.

One idea runs through all of it: try to seeyour project through the vendor's eyes. Vendors are choosing their clients too.The municipalities that are well prepared get the best teams, the bestproposals and, most often, the best outcomes.

1. Agree on what "ERP" means for you

Write down which functions your ERP includesand get leadership to sign off before you go to market. It sounds basic, butit's one of the most common gaps we see.

The textbook definition is simple: a suiteof business applications that share common data, usually finance, HR andpayroll, and procurement. In a municipality, the edges get blurry. Tax, utilitybilling, budgeting and permitting may or may not be in.

The bigger issue is that everyone hearssomething different. Finance hears "general ledger." HR hears"payroll." IT hears "platform." Council might hear"one system that fixes everything," or "a big bill that lands onthe tax rate." Every one of those expectations ends up in your project.

When the definition stays fuzzy, threethings tend to happen:

•        Scope creeps to cover every department'swish list.

•        The budget grows right along with it.

•        People are disappointed by things thatwere never actually in scope.

Two myths are worth naming. First, ERPdoesn't have to mean one system that does everything. Some mid-sizedmunicipalities are now weighing separate HR and finance systems against asingle full ERP, and that's a legitimate choice. Second, a new system won't"just plug into" everything you already have. Every system you keepis a decision, and an integration someone must build and maintain.

Finally, decide what "better"looks like. If the goal is for the new system to do what the old one did,that's replication, not modernization. As one vendor put it, clients oftendon't stop to look at how much better things can be.

2. Put a senior leader in charge, and budget for the wholejourney

An ERP replacement should be led by asenior leader, not by IT, and it should be funded for the full life of thesystem and the people who make it work.

Treat it as a change project

Getting to "better" meanschanging how people do their jobs. Many municipalities pay for animplementation but expect a transformation. Twenty years ago, we bent ourprocesses to fit the software. This time let's do it the other way around.

That means planning for change managementfrom day one and protecting it in the budget. It's usually the first line toget cut, and it's rarely something you can hand to an existing employee as aside job. One vendor put it bluntly: you can't simply appoint someone in-houseas the change manager for a transformation of this size.

Budget for the full life, and for people

•  Cost the full life of the system. Ifyou'll use it for 20 years, don't cost it for 2 or 3.

•  Backfill the staff you move onto the project. Their day jobs don't disappear.

•  Hold contingency for blind spots. In arenovation, you don't find the mold until the drywall comes down. In an ERPproject, messy data is usually the mold.

What to expect by size

The size of your municipality largelydetermines which tier of solution fits, and roughly what it will cost.

Treat population as a starting point, notthe answer. A general rule from one implementer is roughly one municipalemployee for every ten residents. Some larger platforms also have minimum usercounts for HR and payroll, which is why there are separate tiers for different sizesof municipalities. We'll come back to judging fit in section 4.

3. Get educated before you go shopping

Learn themarket, decide what's in and out, and show vendors you're ready, all before youstart your procurement process.

You don't know what you don't know

We hear this question all the time:"Why can't we talk to vendors before we start procurement?" You can,and you should, as long as it's fair and compliant. You'd research a new fridgebefore buying one. A 20-year ERP decision deserves at least as much homework.

• Talk to peers who've been through it. Askabout their experience, resourcing, cost and scope.

• Run a simple RFI. A short request askingabout capabilities, with a video of core functionality, is the lowest-effortway to get informed.

• Use cooperative purchasing vehicles likeOECM and Canoe to explore platforms and implementers informally. Vendor daysand demos are education, so they won't compromise a fair process later.

• Bring the whole team along. If only oneperson learns about the market, that knowledge is siloed and impacts the team'sjourney.

Decide what's in and what's out

Talk about your business, not the systems.Make conscious choices about all core, and peripheral (but important functions)such as budgeting, tax, utility billing, learning management, applicanttracking and procurement, etc. and know why you're keeping or replacing eachone.

Count your interfaces honestly, too. Onevendor shared they saw one RFP that listed 25 interfaces when only 15 wereactually needed once the capabilities of the system were understood. Everyextra one adds cost and risk.

Get to know your data while you're at it:where it lives, how clean it is and who owns it. Messy data is the surprisethat catches most projects off guard.

Watch out for narrowing the market byaccident. Requirements like "must include integrated tax, utility billingand water" or "must be cloud" can quietly rule out good options.Settle those questions before you procure.

And don't decide modules in isolation. AnHR-only or recruitment-only RFP driven by today's pain point can leave you witha patchwork of systems that don't share data, security or reporting. Phasing isfine, but each phase should fit a picture of your whole back office.

Stand out in a crowded market

Picture everyone leaving the hockey gameand heading to the same restaurant. That's the ERP market right now. Manymunicipalities are releasing RFPs at the same time, often with the same closingdates, and several legacy platforms are reaching end of life at once. Somevendors can only take on 10 to 15 conversions a year.

So, vendors pick where they respond. Aclear, well-prepared RFP signals that you have your act together, and itattracts vendors who are a good fit. If you know you need to move, start now.As one vendor told us, they'd much rather hear early that they're not a fitthan have both sides spend months finding out the hard way.

4. Buy against your goals, not a giant checklist

Buy the right size of solution againstclear outcomes and clear scope. Thousands of requirements won't get you there.

Be honest about fit

The tier table in section 2 is a startingpoint. Real fit also depends on whether a product can scale up or down, theresources you'll have to run it, how complex your organization is, and yourfinancial and technical capacity. You also have to consider how your populationwill grow not just where it’s at now. It's shades of grey, so be honest aboutwhere you sit.

Apples and peaches

An RFP is designed to compare apples toapples: Honeycrisp versus Granny Smith versus McIntosh, all scored on the samegrid. It feels fair. But what if the best answer for your municipality is apeach? Great insight from one of our interviewees.

A rigid scoring grid can't see it. Andvendors won't propose it, because anything outside the grid costs them pointsand raises their price. So, you end up choosing the best apple, even when youreally needed a peach.

The fix is to focus on the what and the why,and let your vendors tell you the how and when. In practice, that looks like this:

• Define the outcomes you want, plus aboutten must-haves per business area that vendors demonstrate live.

• Skip the endless requirements list.Thousands of lines make evaluation impossible, and vendors increasingly answerthem with AI tools, so a "yes" on every line tells you very little.

• Spell out your scope. Be explicit aboutthe modules, interfaces and services you're buying. A list of requirementsisn't a scope of work.

Be careful with price weighting

Because of how prorated price scoringworks, a heavy price weighting means only the lowest or second-lowest biddercan realistically win. One vendor told us that when price is scored at 30% ormore, it might as well be 100%.

Vendors respond by stripping proposals downto the minimum, and the missing pieces come back later as change requests. Ifprice could disqualify a vendor, consider opening pricing before multi-daydemos rather than after.

Get the right help

Most procurement officers have never runanything this big, so decisions can get made out of fear: keep us off the frontpage and out of court. That's understandable, but a process so restrictive thatvendors can't propose a better approach protects the process, not the outcome.An experienced advisor and procurement specialist should simplify things, notadd layers.

5. The people make the project

The right people on both sides of the tablematter more than the software. If you take one thing from this guide, make itthis one.

You're buying a team, not a logo

A firm's credentials matter much less thanthe people who will actually show up. Yet most municipalities never ask to seethe proposed team. As one vendor said, that's a little bit crazy.

Municipal knowledge isn't optional, either.Knowing a platform inside out is not the same as understanding municipalfinance, property tax, utilities or public procurement. You can't changeprocedures well if you don't understand the work in the first place.

Questions worth asking a prospective partner

1. Who specifically will be on ourproject, and what percentage of their time will they spend on it?

2. Which municipalities like ourshave you implemented, and can we talk to them?

3. What happens if a key person onyour team leaves partway through?

4. Who owns this product, and whatis its roadmap for the next 10 years?

5. What would make you decidewe're not a good fit?

6. Based on your experience, whatwould you recommend we do differently from what our RFP asks?

See the real team before you sign

•  Make demos a conversation, not aperformance.

•  Add an unscored "for information only" session so you can ask open questions freely.

•  Judge depth of knowledge over polish.

•  Write named key personnel into the contract.

Your side of the table matters just as much

Hiring a vendor doesn't hand overresponsibility. The municipality owns the project. The vendor's project managerworks for the vendor, so you need your own.

Plan for the people you'll pull onto theproject. Backfilling a key role can take three to six months, so budget for itearly and plan for succession. If key staff are retiring, involve the peoplewho'll be running the system after them. Don't buy a system for yourreplacement without them in the room.

Side-of-desk resourcing, where staff try tofit the project around their full-time jobs, slows every decision. It's one ofthe leading reasons municipalities aren't ready at go-live.

6. Keep leaders in the room and decide quickly

Delivery runs on fast decisions made at theright level. That means your executives need to stay involved after thecontract is signed.

In one Ontario city we worked with, thesteering committee included the CAO, the Director of Corporate Services, theCFO and IT. Problems went straight to the people who could solve them, and theproject succeeded largely because the CAO stayed engaged.

Executives often push decisions down, butERP decisions are business decisions for the whole institution, not technicalones. Leaders don't need to handle the day-to-day, but they do need to own thebig calls.

• Decide fast and stick to it. Revisitingdecisions is one of the most expensive patterns we see, in cost, time andfrustration on both sides.

• Expect change requests. Like arenovation ("I don't like these cabinets"), they're inevitable andcome from both sides. Manage them through governance rather than trying toprevent them.

• Phase the rollout, and let someone withreal authority decide when processes change.

• Make testing business-owned, with cleargo/no-go criteria, and start cleaning and migrating data early, with businessowners assigned to it.

7. Remember that go-live is the beginning

Plan and fund the years after go-livebefore you even write the RFP. ERP is a program, not a one-time project.

Operational readiness is the most commonreason clients end up unhappy, and the implementer often gets the blame. Askyourselves early: who will handle quarterly updates, testing and brokenintegrations once the vendor's team has moved on?

Plan for three stages after launch:stabilizing, then enhancing, then continuous improvement. Give each one a namedowner and a budget.

\