ERP Selection for PE Portfolio Companies

Executive summary

ERP selection for PE portfolio companies is a different decision from ERP selection in a company that expects to own its system for twenty years. The hold period is finite, the next buyer will examine the system in diligence, and the management team usually has no spare capacity to run a multi-year implementation while also delivering the value creation plan.

That changes the questions. The first question is not "which ERP?" It is "does this company need a new ERP, or does it need its current one configured, cleaned up, and reported on properly?" Many replacement projects are really reporting projects, data projects, or process projects that happened to be blamed on the software. Replacing the system does not fix them, and it adds a migration on top.

When replacement is the right call, the decision should rest on four things: requirements written from the company's own processes, weights agreed before any vendor demo, a five-year cost comparison that includes internal labor and integration, and a migration and cutover plan with named owners and a rollback point. This guide walks through each, with templates you can copy.

Nothing here endorses a product. Licensing, contract, and data-protection terms belong with your counsel and your own agreements.

When to use this

Use this guide when:

• The current ERP is at or near end of support from its vendor, or a major version upgrade is required anyway.
• A new platform acquisition or add-on brings a second ERP into the portfolio, and someone asks whether to consolidate.
• Month-end close depends on spreadsheets that exist because the system cannot produce the number.
• The renewal for the current system is approaching and the price or terms have changed (see The Tech Tax and the SYSPRO renewal analysis for how to read that situation).
• The sponsor or a lender has asked for reporting the current system cannot deliver.

Do not use it to decide on a replacement before you have tested the cheaper alternative: fixing master data, tightening configuration, and building reporting on top of the current system. The data foundations guide covers that path.

Diagnostic questions

Answer these before any vendor conversation. Write the answers down; they become the requirements document.

1. What specific business outcome is not achievable today, stated as a process or a report, not as "the system is old"?
2. Is the limitation in the software, in how it is configured, in the data held in it, or in the people and process around it? How do you know?
3. Which processes run outside the ERP in spreadsheets or side tools, and how many hours per month does each consume?
4. Who in the company can describe the order-to-cash and procure-to-pay flows end to end, and are they available to be on the project?
5. What does the current vendor's support and upgrade path look like for the next three years, according to their written policy?
6. How many legal entities, currencies, locations, and sales channels must the system handle now, and in the planned hold period?
7. What integrations exist (EDI, shipping, payroll, CRM, banking, e-commerce, plant systems), and which are customized?
8. How clean is master data: customers, items, vendors, chart of accounts? When was it last audited?
9. What is the expected hold period remaining, and how would a buyer view a system change in the middle of a sale process?
10. What is the company's tolerance for a close or shipping disruption during cutover, and which month or season is off limits?
11. What internal capacity can be released to the project without breaking day-to-day operations, expressed in named people and hours per week?
12. Has anyone priced the "stay and fix" option with the same rigor as the replacement options?

If questions 2 and 12 cannot be answered with evidence, you are not ready to run a selection. You are ready to run a short assessment.

Framework: replace, re-implement, or reinforce

There are three real options, and a selection process should evaluate all of them against the same criteria.

Evaluate each on five dimensions: process fit, data readiness, implementation risk, five-year cost, and effect on exit. Effect on exit is the one most teams skip. A buyer's diligence team will ask when the system was last implemented, whether it is stable, whether the close runs on it, and whether the integrations are documented. A half-finished migration at the time of sale is a negotiating issue. A stable, documented system with clean reporting is not.

Step-by-step process

1. Frame the decision and set the decision rule. Owner: CEO with the CFO. Output: one page stating the business outcome, the three options, who decides, and the date by which the decision must be made. Include a statement of what would make you stay with the current system.
2. Map current processes at the level that matters. Owner: Controller and operations lead. Output: order-to-cash, procure-to-pay, inventory or service delivery, and record-to-report flows, each with the systems and spreadsheets touched, volume per month, and known workarounds. Do this from the people who do the work, not from the vendor's process template.
3. Write requirements as outcomes. Owner: CFO. Output: a list of 30 to 60 requirements, each tagged must-have, should-have, or nice-to-have, with the process it supports. Write "produce a consolidated close across three entities in a stated number of working days" rather than "multi-entity support."
4. Audit data readiness. Owner: data owner (see the data foundations guide). Output: counts of customers, items, vendors, open transactions; duplicates; missing fields; a clean-up estimate in hours.
5. Set weights before demos. Owner: selection committee. Output: a signed-off scorecard (template below). Agree the weights while nobody has seen a product, so enthusiasm for a demo cannot move them.
6. Build the long list and cut it. Owner: CFO and an independent adviser if one is used. Output: three to five candidates, chosen on fit to your requirements and the ability to support your industry, entity structure, and size. Remove candidates that fail a must-have in writing.
7. Run scripted demonstrations. Owner: process owners. Output: each vendor performs your scripted scenarios with your sample data (for example, a partial shipment with a price adjustment and a credit memo), not their standard demo. Score immediately after each session, individually, before discussion.
8. Check references and implementation partners. Owner: CFO. Output: calls with customers of similar size and complexity, and with the named implementation team, not just the vendor's sales organization. Ask what went wrong and what the customer would do differently.
9. Build the five-year cost comparison. Owner: FP&A. Output: the table in the template section, including internal labor, integrations, and backfill. Ask for all pricing in writing, and have counsel review commercial terms, renewal uplifts, data-return rights, and exit provisions.
10. Plan migration and cutover. Owner: project lead with the Controller. Output: a migration scope (what history moves, what is archived), a cutover calendar that avoids quarter-end and audit, parallel-run criteria, and a rollback point.
11. Decide and record. Owner: the decision maker named in step 1. Output: a one-page decision memo with the scores, the cost comparison, the risks accepted, and the assumptions that would trigger a reassessment.
12. Set the governance. Owner: steering group. Output: a monthly meeting, a scope change-control rule, and a cutover go/no-go checklist.

Templates

Weighted scorecard (copy into a spreadsheet)

Score each criterion from 1 to 5 using a written definition for each score. Weighted score = sum of (weight x score) divided by 100.

Five-year cost comparison

Cutover go/no-go checklist

Metrics and KPIs

Setting targets without invented benchmarks. Do not take a typical overrun figure from an article and apply it. Set contingency by method: look at the company's own previous projects and compare the first approved estimate with the final actual, and use that ratio as a starting point. Set the close target against your own best trailing close, then against a named public peer's disclosed timetable if one exists. Set the migration data-readiness threshold by agreeing with the Controller which error rate would make the opening balances unreliable.

Common mistakes

1. Buying on the demo. Standard demos show the product at its best with ideal data. Scripted scenarios with your own messy cases show you the product you will own.
2. Setting weights after seeing the products. Weights move toward whatever the favorite does well. Fix them first and keep a record.
3. Leaving internal labor out of the cost. The people who know how the company really works are the ones the project needs most. Their time, and the cost of backfilling it, is a real line.
4. Replicating the old system. Moving every customization and report across keeps the old complexity. Challenge each one: what decision does it support, and who uses it?
5. Ignoring data quality until migration. Duplicates and inconsistent item masters show up as errors in the new system and get blamed on the software.
6. Cutover at the wrong time. Quarter-end, year-end, audit, or a peak shipping season puts the close and customer service at risk at once.
7. Underestimating change management. Users who were not part of the design reconstruct their old spreadsheets within weeks.
8. Skipping the exit view. A mid-migration system in a sale process is a diligence finding. Plan the timing against the likely exit window.

Worked example

Illustrative. The figures below are invented to show the method. They are not benchmarks, and no product is implied.

A portfolio manufacturer is deciding between Option A, a new cloud ERP, and Option B, upgrading its current on-premises system. The committee set weights in advance and scored after scripted demos.

Weighted score: A = 350 / 100 = 3.50. B = 340 / 100 = 3.40.

Five-year cost, in thousands of dollars:

Annualized: A = 2,020 / 5 = 404 per year. B = 1,680 / 5 = 336 per year.

What this tells the committee:

• The scores are close: 3.50 against 3.40. The decision should not be made on a 0.10 gap. Test how sensitive it is: if the weight on fit rises from 25 to 30 and reporting falls from 15 to 10, which option leads?
• B costs 340 less over five years but scores lower on migration risk, implementation risk, and reporting access. Those are risks the cost line does not price.
• B has the higher integration cost (200 against 120) because custom integrations must be rebuilt for the upgrade. That is the type of line that disappears from vendor quotes.
• The next step is not a decision. Price the "reinforce" option with the same table, and check each option against the expected exit date.

AI prompt assistance

AI can speed up requirements drafting and comparison, but you supply the facts and verify every figure. Do not paste confidential contract text into a tool unless your policy allows it.

1. Turn process notes into requirements.

Here are my notes on our order-to-cash process, with the steps, systems, and workarounds. Convert them into a list of requirements phrased as outcomes. Tag each must-have, should-have, or nice-to-have, and quote the line of my notes that supports the tag. List any step where my notes are ambiguous.

Check: have each process owner confirm their requirements and remove any that were invented rather than quoted from the notes.

2. Build scripted demo scenarios.

Using these requirements, write eight demo scenarios a vendor must perform with our sample data. Each scenario should include the starting condition, the steps, and the expected result so that two scorers would score it the same way.

Check: run each scenario past a user who does the task daily, and confirm that the expected results are what the business really needs.

3. Reconcile a cost comparison.

I will paste two five-year cost tables. Add each column, check the totals, flag any line that is missing in one option but present in the other, and list assumptions that appear to differ (for example, uplift rates or hosting).

Check: recompute the totals in a spreadsheet and confirm each flagged difference against the vendor's written quote.

4. Summarize reference-call notes.

Here are notes from four reference calls. Group the comments by theme (data migration, partner quality, support, change management, cost overruns). For each theme, say how many calls mentioned it and quote the relevant line. Do not infer opinions that are not in the notes.

Check: confirm each quote against your original notes.

Implementation guide

Governance: the sponsor owns the decision and the budget, the CFO owns the requirements and the close, the project lead owns the plan, and the Controller owns the opening balances. Report plan variance and the status of the go/no-go checklist monthly. Treat any change to the hold-period plan or the exit timeline as a trigger to reassess.

What to expect: selection takes weeks, but implementation and stabilization take much longer and consume finance and operations in ways a vendor timeline does not show.

Downloadable assets

The weighted scorecard, five-year cost comparison, and cutover go/no-go checklist above are designed to be copied into a spreadsheet. There is no calculator for ERP selection. If the current system is a SYSPRO environment and a renewal is approaching, the SYSPRO renewal calculator can help you size the cost of staying before you compare options.

Related resources

• Technology guides hub: the full set of technology and systems guides.
• Data foundations for operating reporting: clean master data and reporting before or alongside a system change.
• Build vs buy for internal tools: the same discipline applied to smaller decisions.
• SaaS and vendor renewal calendar: protect your leverage on contracts you are about to renew.
• Technology due diligence for operators: how a buyer or investor reads your systems.
• IT integration in post-merger integration: when ERP consolidation is part of an acquisition.
• AI use case prioritization framework: where to spend technology effort.

Frequently asked questions

When should a portfolio company replace its ERP?

A portfolio company should replace its ERP when the limitation is in the software's process fit or vendor support path, not in data, configuration, or reporting. Test the cheaper option first: clean master data, fix configuration, and add reporting. If core processes still cannot run, and the hold period leaves time to stabilize, replacement is justified.

How do you compare ERP options fairly?

Compare options with a scorecard whose weights were fixed before any demo, scripted demonstrations using your own scenarios, and a five-year cost table with the same lines for every option. Include internal labor, integrations, and data migration. Score individually after each demo, then discuss, so no single voice shapes the result.

How long does an ERP implementation take?

Duration depends on scope, data readiness, the number of entities and integrations, and how much internal capacity is available, so no single figure fits every company. Ask each implementation partner for a plan by phase and compare it with the pace of your own past projects. Treat any plan that ignores your close calendar as incomplete.

What should be in the cost of an ERP project?

The cost should include subscription or maintenance, hosting, implementation fees, internal labor and backfill, data migration, integrations and customizations, training, and a contingency. Contingency is best set from the company's own history of estimate versus actual on prior projects. Contract terms, renewal uplifts, and exit rights should be reviewed by counsel.

How does an ERP change affect a future sale?

A buyer's diligence will examine system stability, the close process, integration documentation, and any in-flight migration. A stable, documented system with clean reporting helps. A half-finished migration creates a finding and can affect negotiation. Time the project against the likely exit window and keep records of decisions and test results.

How this works in a System of Performance

An ERP decision is made once, but its assumptions keep mattering: which requirements were must-haves, what the cost model assumed, which risks the committee accepted. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want a view of how your own systems and data hold up, bring it to us as a launch partner.