What Canadian Municipalities Should Map Before Moving Off Dynamics GP

Before moving off Microsoft Dynamics GP, Canadian municipalities should map the workflows, reports, integrations, data structures, municipal add-ons, controls, and timing dependencies that keep daily operations and year-end reporting running. The biggest migration risk is not the software replacement itself. It is discovering too late that critical finance, tax, utility, payroll, or reporting processes were never fully documented.

A Dynamics GP migration should begin with current-state mapping before procurement, configuration, or cutover planning begins.

Why mapping matters before a Dynamics GP migration

Many municipalities have used Dynamics GP for years, often alongside spreadsheets, Management Reporter, municipal add-ons, tax systems, utility billing systems, payroll tools, document repositories, banking connections, and manual approval processes.

Over time, the real operating model may no longer be visible in one system. It may exist across reports, Excel files, staff knowledge, monthly routines, audit schedules, and workarounds created to keep municipal operations moving.

That is why migration planning should not start with a list of features. It should start with a clear map of what the municipality actually does today.

1. Map finance and fund accounting structures

Start with the finance foundation.

Municipalities should document:

• General ledger structure
• Chart of accounts
• Fund structures
• Departments
• Cost centres
• Projects
• Grants
• Reserves
• Restricted and unrestricted funds
• Interfund activity
• Year-end adjustments
• Recurring journal entries
• Financial statement mapping

This is especially important for PSAB reporting readiness. If the current chart of accounts, fund structure, or reporting hierarchy is poorly understood, the future system may recreate the same complexity in a new environment.

2. Map PSAB and year-end reporting dependencies

Dynamics GP migration can affect PSAB reporting because many year-end processes depend on reports, extracts, spreadsheets, and supporting documentation outside the core system.

Municipalities should identify:

• PSAB reporting schedules
• Year-end working papers
• Audit evidence files
• Deferred revenue schedules
• Grant reporting
• Reserve continuity schedules
• Tangible capital asset schedules
• Amortization support
• Post-employment benefit inputs
• Pension-related handoffs
• Council or board reporting packages

The goal is to understand which reports and evidence trails must continue after migration.

3. Map Management Reporter and Excel dependencies

Many Dynamics GP environments rely heavily on Management Reporter and Excel-based reporting.

Before migration, municipalities should document:

• Reports used monthly
• Reports used only at quarter-end or year-end
• Reports required for audit
• Reports used by council or leadership
• Excel files fed by GP exports
• Manual formulas or adjustments
• Distribution lists
• Report owners
• Reports that are no longer used

This step often reveals hidden risk. A report may look simple, but it may support a critical reconciliation, grant claim, reserve schedule, or audit request.

4. Map data that must move, stay accessible, or be archived

Not every data element needs to move into the new system in the same way. Some data must be converted, some may need read-only access, and some may need to be archived for audit or records purposes.

Municipalities should classify:

• Vendors
• Customers
• Employees or payroll references
• Funds
• Accounts
• Projects
• Grants
• Assets
• Open transactions
• Historical transactions
• Attachments
• Audit evidence
• Bank records
• Tax or utility references
• Opening balances

For each data set, define whether it must be migrated, summarized, archived, validated, or retained for reference.

5. Map integrations and municipal handoffs

Dynamics GP rarely operates alone in a municipality. It may receive or send information to multiple systems.

Common handoffs include:

• Property tax
• Utility billing
• Payroll
• Banking
• Procurement
• Document management
• GIS
• Asset management
• Work orders
• Citizen service systems
• Payment processors
• Reporting tools

Each integration should be mapped by source, destination, owner, frequency, file format, timing, validation step, and failure handling process.

6. Map municipal add-ons and side systems

Some municipalities have municipal-specific add-ons or side systems connected to Dynamics GP. These may not be obvious during a high-level system review.

Document:

• Add-ons connected to GP
• Custom reports
• Import/export tools
• Approval workflows
• Legacy databases
• Access databases
• Shared drives
• Spreadsheet trackers
• Vendor-built utilities
• Staff-created workarounds

If these dependencies are not mapped early, they can become late-stage migration blockers.

7. Build a RICE inventory

A RICE inventory helps municipalities understand the technical and functional work needed for migration.

RICE stands for:

• Reports
• Interfaces
• Conversions
• Extensions or enhancements

For each item, capture: Name, business owner, purpose, frequency of use, source system, target system, data fields, complexity, migration requirement, testing requirement, and retirement decision. Not every RICE item should be rebuilt. Some should be replaced by standard functionality, redesigned, simplified, or retired.

8. Map roles, approvals, and controls

Migration planning should include people and controls, not only data.

Document:

• User roles
• Approval paths
• Segregation of duties
• Finance approvals
• Purchasing approvals
• Payroll handoffs
• Journal entry controls
• Bank reconciliation responsibilities
• Audit access needs
• Security groups
• Reporting permissions

This helps avoid disruption after go-live, especially during the first close or first audit cycle.

9. Map blackout periods and timing constraints

Municipal timing matters. A migration plan must respect operational cycles.

Identify blackout or high-risk periods such as:

• Month-end close
• Year-end close
• Audit preparation
• Budget season
• Tax billing
• Utility billing
• Payroll cycles
• Council reporting deadlines
• Grant reporting deadlines
• Major public-service windows

A technically clean migration can still fail operationally if it conflicts with municipal reporting or billing cycles.

10. Map first-cycle stabilization needs

The first cycle after go-live is where many issues appear.

Municipalities should plan support around:

• First financial close
• First AP run
• First AR cycle
• First bank reconciliation
• First reporting package
• First tax or utility handoff
• First payroll-to-finance handoff
• First audit request after migration
• First correction or adjustment process

This is where current-state mapping becomes practical. It gives the team a clear checklist for what must work immediately after go-live.

What this means for your municipality

Moving off Dynamics GP is not only a system change. It is a municipal operating-model transition.

Before selecting a future system or finalizing a migration plan, municipalities should understand what GP supports today, what surrounding systems depend on it, what reporting must continue, and which workflows must be protected during cutover.

A good migration map gives finance, IT, operations, and leadership a shared view of risk before implementation begins.

Frequently Asked Questions