What Healthcare Finance Teams Should Budget for in an ERP Migration
The decision to modernize the financial platform is usually made at the strategic level. The decision to fund it is made in much more practical terms. Once a CFO says “we are seriously considering this for next year,” the next question is always the same.
What is this actually going to cost us?
Vendor decks answer that question optimistically. Implementation partner proposals answer it precisely for their scope of work, which does not include everything you will spend. The honest answer requires accounting for all the line items, including the ones that do not show up on either party’s invoice.
This is a budgeting guide for healthcare finance teams preparing to move from a legacy on-premise ERP to a cloud-native platform like Sage Intacct. Numbers will vary with your specific environment, entity structure, and integration scope. The categories and the relative weight of each one tend to hold across mid-market healthcare.
How much should we budget total for an ERP migration?
The honest answer is that year-one all-in cost varies significantly depending on entity complexity and integration scope. Plan for a meaningful capital request that includes platform subscription, implementation services, integration work, internal labor opportunity cost, training, and contingency. Build the budget from your specific environment rather than benchmarks; pattern numbers are not a substitute for a quote against your actual scope.
Year two drops materially once implementation services drop off. Subscription and ongoing optimization become the bulk of the run cost. By year three, total annual run cost is typically lower than the comparable on-premise total cost.
The number that matters more than the headline is the year-by-year cash flow profile. CFOs presenting to capital committees should expect a question about year-one peak spending. Have an answer that includes phasing options.
What is the typical split between platform cost and implementation cost?
In year one, expect platform subscription and implementation services to each represent a substantial portion of the total, with the balance going to integration build, training, internal labor coverage, and contingency.
That “everything else” bucket is where projects most often go over budget. Implementation partners price their scope cleanly. Subscription costs are fixed. The variance lives in the work that sits between the two: integrations, change management, and the operational prioritization required when the team takes on the implementation alongside their existing close responsibilities.
How long does a typical implementation take?
Implementation length varies materially with entity count, integration footprint, and historical customization. A focused, well-scoped Sage Intacct implementation can move quickly; complex multi-entity organizations with extensive EHR integration and significant historical customization take longer. Your implementation partner should be able to give you a firm timeline once they understand your specific environment. Intacct’s multi-tenant architecture means the platform itself does not require a custom build; the implementation effort is concentrated in configuration, integration, and process design.
If the project needs to span a longer timeline, the right approach is to phase by module (going live with core modules first, then adding nice-to-haves), not by entity. Module phasing keeps the full user community engaged in the design phase and avoids the rework that entity-by-entity rollouts typically generate.
The timeline includes structured user acceptance testing in a dedicated test environment, not a parallel run. DSD does not recommend running the legacy system and the new platform side by side; that approach doubles the workload and rarely catches issues that proper test-environment testing would not. The implementation instead includes thorough UAT scenarios for the meaningful transactions: anything complex, anything that occurs on a regular cadence, anything that touches multiple modules. When those scenarios pass cleanly in the test environment, the team is ready to cut over.
Who needs to be on our internal team, and how much of their time?
The implementation partner does the configuration work. Your team owns process design, data validation, user acceptance testing, and change management.
Plan for these internal roles during the implementation window:
| Role | Typical Owner | Time Commitment | Focus |
|---|---|---|---|
|
Project sponsor
|
CFO |
Light
|
Steering committee, escalations, major decisions
|
|
Project lead
|
Controller or VP of Accounting
|
Substantial; effectively a primary role
|
End-to-end execution during active implementation
|
|
Functional leads
|
AP, AR, GL, payroll allocation, consolidation owners
|
Material per lead
|
Process design, configuration sign-off, testing
|
|
IT lead
|
Director of IT or VP of Applications
|
Material
|
Integration design, security, identity management
|
|
Power users / change champions
|
One per business unit
|
Modest, sustained
|
Testing, training delivery, adoption
|
The project lead commitment is the one organizations consistently underestimate. Trying to add a part-time-but-substantial workload on top of an existing full role is the most common reason implementations slip. Plan for explicit workload reallocation, extended deadlines on competing work, or leadership commitment to deprioritize other initiatives during the implementation window.
Beyond the project lead specifically, plan for the broader team to take on additional time and project commitments during the implementation window. The work does not get done unless leadership explicitly prioritizes it, and that prioritization needs to come with a real plan: extended deadlines on lower-priority work, deliberate reallocation of workload across the team, or operational priority shifts. Competing priorities are the most common reason implementations slip or get back-burnered. Recognize that risk upfront and budget for it in both time and cost.
What does year two look like?
Year two budget should reflect three things.
Steady-state subscription costs. The headline platform cost continues at the negotiated rate. Modules added during implementation are now baseline. Module additions in year two are predictable.
Ongoing platform support and optimization. Year two is when most clients move from active implementation services to a steady-state support model. With DSD, that means a service-level agreement: a fixed annual cost that covers platform support, optimization, and release adoption guidance. The SLA replaces what would otherwise be unpredictable hourly consulting invoices, and it keeps the platform improving without forcing the finance team to forecast support spend quarter by quarter.
Training for new hires and refresh training for existing users. The platform is easier to onboard people to than the legacy system, but it is not zero-effort. Plan for an annual training line.
Year two is also when the IT labor recovery starts showing up in real terms. Capacity that was committed to ERP maintenance becomes available for the strategic backlog. Most CIOs do not reduce headcount; they redirect it. That redirection is the largest source of TCO improvement in the model.
What gets cut from the implementation budget that should not?
Three things, consistently.
Data cleanup. The temptation is to start implementation with the data you have and clean it up later. Do not. Open intercompany items, unreconciled accounts, abandoned customizations, and orphaned dimensions are easier to address before migration than after. Build a meaningful pre-implementation window into your timeline for this, and budget for external support if the current GL is in rough shape.
User acceptance testing time. UAT is the workstream most often compressed when timelines slip. Compressed UAT means defects surface in the first live close instead of in the test environment, which is a much more expensive place to find them. Hold the line on UAT duration and the number of test scenarios.
Test data preparation. UAT only works if the test data reflects production realities. Organizations sometimes cut this step, then discover during go-live that scenarios they should have tested never appeared in the test environment. Budget the time to build representative test data, including the edge cases that historically caused problems on the legacy platform.
What are the hidden costs we should account for?
Three categories typically surprise CFOs.
Custom report rebuild. The reports your finance team built over years on the legacy platform need to be evaluated, prioritized, and rebuilt on the new platform. Most will be replaced by out-of-the-box reports. A subset will require custom development. Build a dedicated line item for report migration work.
Add-on and third-party software licensing. Most modern healthcare ERP implementations bring in a few specialized add-ons (AP automation, expense management, advanced budgeting, industry-specific integrations) that carry their own licensing. These costs are not part of the core platform subscription and typically sit outside the implementation partner’s fixed fee. Confirm which add-ons are recommended for your environment, what they cost annually, and which ones are billed by the platform vendor versus the third-party provider.
Audit support during transition. Your external auditors will have additional procedures the first year on the new platform. Plan for higher audit fees in year one. This normalizes by year two, and audit fees typically come in lower than the legacy baseline thereafter.
Should we phase the rollout across entities?
DSD does not recommend phasing the rollout across entities unless the organization absolutely needs to. The cost premium is real and the benefits typically do not materialize.
The bigger issue is design quality. When some user groups are not involved until late in the project, they may surface requirements or workflow concerns that would have shaped the original system design. By the time those concerns surface, the teams already live on the system have to revisit configurations and processes that were assumed to be settled. Training and testing get fragmented across waves, and the user community ends up contributing unevenly to how the platform is built out.
If you need to spread the project out across a longer timeline, phase by module rather than by entity. Go live with the must-haves first (core GL, AP, AR, consolidations, reporting), then layer on the nice-to-haves later (fixed assets, advanced budgeting, additional integrations). Everyone is in the system from go-live, but the platform’s functional footprint expands over time. The cost stays controlled, the full user community contributes throughout the design phase, and the timeline can extend without the design fragmentation that comes with entity-by-entity phasing.
What about change management as a budget line?
Treat change management as a meaningful percentage of total implementation cost. The exact share varies, but underfunding this category is one of the most consistent ways to inherit problems after go-live. The work includes stakeholder communications, training development, user adoption tracking, and resistance management.
Organizations that under-fund this category usually end up paying for it later in three forms: lower user adoption, additional training cost in years two and three, and persistent reliance on workarounds the platform was supposed to eliminate.
When do we budget for additional consulting after go-live?
For DSD customers, the first year of go-live support is included in the statement of work. That covers stabilization in the early weeks, training reinforcement as the team settles into the platform, and optimization work that emerges from the first few close cycles. Most of what other partners price as separate post-go-live consulting hours is already in scope.
Starting in year two, we recommend clients move to a DSD service-level agreement. The SLA is a fixed annual cost that covers ongoing platform support, release adoption guidance as Sage Intacct ships new functionality, and incremental optimization. Fixed cost means predictable budgeting; clients know what their year-two-and-beyond support line looks like without surprise consulting invoices.
What is not in the SLA: net-new projects. If you decide to add a module, integrate a new system, or take on a process redesign that goes beyond optimization, that becomes its own scope and its own budget line. Plan for that work explicitly as it comes up, rather than pre-budgeting for it speculatively.
What is the single most important budget conversation to have early?
The conversation with the CIO about IT labor redirection.
ERP modernization is a finance-led initiative most often, but the largest source of value (and the largest risk if mishandled) is the redirection of IT capacity. If the CIO is not part of the budget conversation, the implementation may succeed technically while failing to deliver the strategic value the model was built on. Plan that conversation early, document the alignment, and revisit it after go-live.
Final Thought
Budgets that work share two characteristics. They are honest about the full cost. And they are explicit about what the organization is buying.
You are not buying a platform. You are buying capacity, speed, and decision velocity. The platform is the vehicle. Treat the budget that way and the conversation with the capital committee gets easier, because you are not justifying software costs. You are justifying organizational capability.
Start the Conversation
DSD Business Systems is a Sage Intacct implementation partner specializing in mid-market healthcare organizations. Our consulting team includes former CFOs, Controllers, and Directors of Finance who built implementation budgets on the client side before they ever built one on the partner side. We know the questions capital committees and audit committees ask, and we know which answers hold up under scrutiny.
If you are heading into fiscal-year planning with ERP modernization on the table, we can walk through a budget framework calibrated to your specific entity count, integration scope, and team capacity. Not a quote. A framework you can defend.
Build a budget your capital committee will believe.
Douglas Luchansky
Director, Client Transformation
