ERP Modernization · October 3, 2026 · 4 min read

Moving municipal ERP to the cloud: what to decide before signing

Seven decisions for a municipal ERP cloud migration, including integrations, data access, operating costs, security responsibilities, and cutover readiness.

By Altioras Civic

Key takeaways

  • Confirm the target service model and the features included in the contract.
  • Price integrations, reporting, internal staff time, and the eventual exit alongside the subscription.
  • Require demonstrated readiness for critical transactions before cutover.

Define what the cloud proposal actually changes

Moving an ERP to the cloud can change hosting, licensing, release schedules, integrations, and the way staff get support. Start by asking the supplier to describe each change in writing. A hosted copy of the current application and a software as a service (SaaS) offering may have different customization and operating arrangements.

For agencies moving from an on-premises municipal ERP, including a Tyler system, the exact product, version, modules, and target offering matter. Confirm those details against the proposal and contract. Product names alone do not establish what will carry forward.

Decide which workflows and customizations to retain

Inventory custom reports, scripts, interfaces, forms, and department-specific rules. For each item, identify why it exists and who relies on it. Decide whether to retain the business requirement, replace the customization with a supported feature, change the process, or retire it.

Let staff demonstrate the work before deciding. A small spreadsheet may be the only place a department tracks an approval or reconciles a financial total. Removing it without replacing that function transfers the problem into the new environment.

GFOA's ERP readiness guidance highlights organizational change, leadership, training, and planning as major project challenges. Treat the cloud move as an operating change with technology dependencies.

Sources: GFOA — 10 Steps to Preparing for Your Next ERP Project

Decide how integrations will operate and be monitored

List every connection to banks, payment processors, timekeeping, meters, GIS, document systems, and external reporting. Record the source, destination, timing, volume, and responsible teams. Ask the supplier to confirm supported methods and any additional licensing or implementation charges.

For each integration, define what happens when a record fails, a file is duplicated, or an expected transfer does not arrive. Assign someone to review exceptions. A successful demonstration of data movement is only part of acceptance; staff also need a way to detect and repair failures.

Decide how the agency will use and recover its data

Confirm how staff obtain operational reports, historical transactions, attachments, and audit trails. Ask whether existing reporting tools will continue to work and what access limits apply. Test a representative export before relying on a promise that the data is available.

Separate provider recovery from agency access to records. Review backup and restore arrangements, retention settings, incident notification, and the process for correcting an erroneous bulk change. Define an exit deliverable with usable formats, related identifiers, timing, and costs.

Decide who owns each security and support task

Cloud services divide responsibility between supplier and customer. Microsoft's shared responsibility documentation, for example, identifies customer responsibilities for data, identities, accounts, and access across cloud models. Use that principle to ask your ERP supplier for a responsibility matrix specific to its service.

Name who creates and removes accounts, reviews privileged access, approves configuration changes, monitors interfaces, and responds to incidents. Agree on support coverage, escalation paths, maintenance communications, and how the agency tests changes before production use.

Sources: Microsoft Learn — Shared responsibility in the cloud

Decide what the full operating cost includes

Compare costs over the same planning period and use explicit assumptions. Include subscription charges, implementation, integrations, conversion, training, internal staff coverage, reporting tools, and legacy record access. Review what happens when transaction volumes, user counts, or modules change.

Identify which fees are fixed, usage-based, or subject to renewal increases. Ask for the costs of test environments, storage, extra support, and exporting data at contract end. A lower hosting expense can coexist with a higher total operating cost.

Decide when the agency is ready to cut over

Schedule around the agency's payroll, utility billing, fiscal close, and reporting obligations. Require repeatable conversion rehearsals and reconciliation of the balances and records staff will depend on.

Before signing, ask the proposal team to show how a critical transaction, a failed integration, and a historical record request would work in the target service. The answers should appear in the implementation scope and acceptance conditions so they can be verified later.

  • Approve data mappings and reconciliation rules with department owners.
  • Confirm staff can complete representative tasks using their assigned access.
  • Document the final conversion window and service contingency arrangements.
  • Name the person who can defer cutover if required conditions are unmet.

References