Localtech Eye

Moving off an old council finance system: a plan

By Local Technology Partners

For Australia, New Zealand

Many councils run finance and rating on a system that is older than some of their staff. It still works, mostly. But each year it costs more to keep, and fewer people know how it works. At some point the council decides to move. This guide sets out a plan for that move, from the first decision to the first month after go-live.

The plan is general. It does not depend on which system you leave or which system you choose. Where we need to refer to a typical incumbent system, we call it "SoftwareX". This guide is not legal or financial advice. Check your obligations with your own advisers and your state or national regulator.

Why councils move

Councils rarely change a finance system for one reason. These are the usual reasons, often together:

  • The supplier ends support for the version the council runs, or for its database or server.
  • The council must buy new servers, or the old ones are a security risk.
  • Licence and support costs rise each year, with no new value.
  • Key staff who know the system retire or leave.
  • Modules do not share data, so staff copy information between them.
  • Residents expect online services, such as reports with photos and status updates, that the old system cannot give.
  • The auditor raises the same findings each year about manual steps and controls.

Write down your reasons before you start. They become the measures of success for the project, and they help you say no to scope that does not serve them.

Step 1: Set the scope

Decide which areas move, and which stay where they are for now. A council ERP usually covers:

  • finance: the general ledger, budgets, accounts payable, purchasing and accounts receivable
  • property and rating
  • assets and works
  • payroll and human resources
  • customer requests
  • permits, licences and registrations
  • records management

You do not have to move everything at once. Some councils move finance and rating first, then payroll, then the rest. Others move everything on one date. A single move is shorter, but riskier. A staged move is safer, but you must run links between the old and new systems for longer.

For each area, record:

  • the current system and who owns it
  • the interfaces in and out, such as the bank, the payroll bureau and the valuer
  • the reports that the council, the auditor and the state need from it
  • the people who use it every day

Step 2: Pick the timing

Timing matters more in local government than in most businesses. Plan around the fixed points in the council year.

  • The end of the financial year. Moving the general ledger at the start of a financial year is cleaner, because opening balances are simpler. In Australia this is 1 July. In New Zealand most councils use 1 July too. Check your own year.
  • Rates notices. Do not go live on rating in the weeks before a rates run. Plan to run your first rates notice in the new system with time to check it.
  • The audit. Talk to your auditor early. They will want to see how you check that balances moved correctly.
  • Elections and budgets. Avoid a go-live in the weeks around a council election or the budget adoption.
  • Staff leave. Christmas and school holidays are poor times for training and cutover.

Work back from the go-live date to set the dates for data loads, testing and training.

Step 3: Understand your data

Data is the largest risk in most moves. The new system will only be as good as what you load into it. Start on data early, before you pick a supplier if you can.

Decide what to move

Not every record needs to move as a live record. A common split:

  • Move as live data: open balances, current properties and owners, current rates and arrears, current assets, open purchase orders, open customer requests, current employees and their leave balances.
  • Move as history: a set number of years of transactions, so staff can answer questions and run comparisons.
  • Archive, do not move: older history. Keep it in a read-only form that staff can search, and keep it for as long as your records rules say.

Your records officer must agree the plan for archives. Councils have legal duties to keep many records for set periods. These differ between states and countries, so check the rules that apply to you.

Clean before you move

Old systems collect old mistakes. Use the move to fix them:

  • duplicate owners and suppliers
  • properties with missing or wrong addresses
  • general ledger accounts that nobody uses
  • assets that no longer exist
  • open requests and orders that were finished years ago

Cleaning in the old system, before the move, is usually easier than cleaning in the new one.

Map and test

Map each field in the old system to a field in the new one. Then load the data into a test copy of the new system, check it, fix the mapping and load it again. Plan for at least three test loads. Each load gets faster and cleaner.

Step 4: Plan the reconciliation

The council must prove that the new system holds the same balances as the old one. Agree the checks before the first test load:

  • trial balance by account, old and new
  • total rates outstanding, and by property for a sample
  • debtors and creditors by account
  • asset register totals by class
  • leave balances by employee

Record each check, who did it and the result. The auditor will ask for this.

Step 5: Interfaces and integrations

List every system that sends data to the finance system, or takes data from it:

  • banks and payment providers
  • the payroll bureau or superannuation funds
  • the valuer and the state land registry
  • the council website and online payments
  • GIS (geographic information system) mapping
  • customer request channels, such as phone, email, web forms and apps

Decide, for each one, whether it moves, changes or stops. Interfaces are often the last part to work, so test them early.

Customer requests deserve special care. Residents keep reporting problems on the day of the move. Make sure that open requests move with their history, and that new requests during the cutover have somewhere to go. A resident app that can send reports by email during the move, and directly into the new system afterwards, removes one risk from the cutover weekend.

Step 6: Test with real work

Test the new system with the council's real work, not only with the supplier's scripts. Ask the people who do the work to run it:

  • raise a purchase order and pay a supplier
  • run a rates notice for a sample of properties
  • take a payment and apply it to a property
  • log a customer request, assign it, turn it into a work order and close it
  • run a pay run and compare it to the old system
  • produce the month-end reports

Run at least one full month-end in the test system. If you can, run a parallel pay run before go-live.

Step 7: Train the people

A new system changes how people work every day. Plan training for each role, close to the go-live date, so people remember it.

  • Start with a small group of experienced users in each area. They help test, and they help their colleagues after go-live.
  • Train with the council's own data in a test system, not with demonstration data.
  • Write short guides for the tasks that people do every day.
  • Plan extra support for the first two weeks after go-live.

Tell councillors and residents what changes for them, too. A new rates notice layout, a new payment reference or a new way to report a problem all need a short, clear explanation.

Step 8: Cut over

The cutover is the short period when the council stops using the old system and starts on the new one. A typical cutover plan:

  1. Set a freeze date. After it, no new transactions go into the old system.
  2. Take the final data extract.
  3. Load it into the new system.
  4. Run the reconciliation checks from step 4.
  5. Make a go or no-go decision, with named people who can say no.
  6. Switch on interfaces, payments and customer channels.
  7. Keep the old system in read-only mode for reference.

Write the plan by the hour. Name the person who owns each step. Agree a rollback plan in case a check fails.

Step 9: The first months after go-live

Expect problems in the first month. Most are small, but they are visible. Plan for them:

  • Keep a daily meeting in the first two weeks to sort issues by priority.
  • Track each issue to the end, and tell the person who raised it.
  • Check the first month-end, the first rates run and the first pay run with extra care.
  • After three months, review the reasons you wrote down at the start. Did the move fix them?

Who you need on the team

A council does not need a large team, but it needs the right people with time set aside:

  • A sponsor. A senior manager who makes decisions and removes blocks.
  • A project manager. One person who owns the plan and the dates.
  • Area leads. One person each for finance, rating, payroll, assets and customer service.
  • A data lead. The person who knows the old data best.
  • The records officer. To agree what moves, what is archived and for how long.
  • The supplier's team. Agree in writing who does which tasks.

In a small council, one person may fill two or three of these roles. That is normal. Make sure their normal work has cover during the busiest weeks.

What to ask a new supplier

Before you sign, ask each supplier:

  • How do you move data from systems like SoftwareX, and who does the mapping?
  • How many test loads do you plan, and how long does each take?
  • What does a typical cutover weekend look like?
  • Where is our data held, and in which country?
  • Is our data kept apart from other councils' data?
  • Can we export all of our data, at any time, in a standard format?
  • How do customer requests flow into work orders, and how does the resident hear back?

For more on the last question, read ERP for local government: from report to work order.

Start with better reports now

A finance system move takes months. Residents do not wait for it. A council can improve how it takes reports from residents before, during and after the move.

Localtech Eye is a free app for residents to report problems in public places, with photos, a map pin checked against the council boundary, and the resident's contact details. Today, councils receive Eye reports by email, with the photos, the map point, the address and the resident's contact details. Email does not depend on the finance system, so the reports keep arriving on the day of the move. With Localtech Core (in development): a Customer Requests module will receive Eye reports as customer requests. Read more in Citizen service requests: how councils take reports.

Localtech Eye is live for Queensland councils. New Zealand is now taking councils, with no resident service there yet.

Talk to us

If your council plans a move, we are happy to talk about the plan, the data and the customer side. Book a demo to see Localtech Eye with your council's data, or visit the page for councils.