Operations · By Tony Holz · 2 November 2026 · 9 min read

How to switch fire maintenance software without breaking your AS 1851 history

Most fire businesses that are unhappy with their software stay on it anyway, because the history is in there and the thought of losing it is worse than the thing they are putting up with. That fear is misplaced. The history moves with you, all of it, and four records in particular keep the cycle continuous from the first day. This is the method: what carries across, what does not need to, when to cut over, and what to tell the owners whose buildings you look after.

1. Why the switch feels riskier than it is

A fire protection business lives inside a cycle. Every asset on every site has a monthly, six-monthly, yearly or five-yearly routine running against it under AS 1851, and the whole point of the software is to know where every one of those cycles is up to. Changing the software in the middle of all that feels like changing the wheels on a moving truck.

The fear has four parts. That the service history will be lost and the next audit will find a hole. That a routine will slip through during the changeover and a building will miss its window. That the owners and building managers will notice and ask questions. And that the technicians, who have finally learned the current app, will revolt.

Each of those is a real risk if the switch is done badly. Each is a non-event if it is done in the right order. The order is the whole article.

2. The four records that have to carry across

Strip the problem back and the continuity of a fire compliance record rests on four things. If these four arrive intact in the new system, every cycle continues exactly where it left off and the logbook is unbroken.

The asset register. Every extinguisher, detector, hose reel, pump, door and panel, with its type, its location on the site, its tag or barcode number, and the site and client it belongs to. This is the spine. Everything else hangs off it.
Test readings and reference figures. Pump pressures and flows, hydrant residuals, discharge durations, battery capacities: the figures each yearly and five-yearly result is judged against. They come across with each test's history, so the next result has its predecessor to compare with. These are the records most often lost in a handover, and the hardest to reconstruct afterwards.
Open defects. Every defect that has been found and not yet closed, with its classification, the date it was raised, the notice issued, and any quote outstanding. Closed defects are history. Open defects are live obligations and must not be dropped.
The last-done date for every routine on every asset. When each monthly, six-monthly, yearly and five-yearly activity was last completed. From that one date per routine, the entire forward schedule is computed. Get it wrong and the new system either thinks everything is overdue or thinks nothing is.

These four are the records that keep the cycle continuous on day one. They are not the only things that move. The full service history behind them comes too, and so does the commercial layer: the client and site list, the contacts, and the contract and billing schedule for each site. All of it carries across in the same week.

3. The whole history comes with you

The closed history is not left behind in the old system or flattened into a folder of PDFs. Every past inspection, test result, reading, defect and close-out is imported into the new platform against the asset it belongs to, so that a technician who scans an extinguisher on their first visit sees the same eight years of monthly checks they would have seen a month earlier, and an assessor reading the record sees one unbroken line.

This matters more than it sounds. Yearly and five-yearly results are compared against the previous ones. Defect histories show whether a fault is new or recurring. An owner asking for the service record for a building expects the whole record, not the part since the software changed. Importing the history in full is what makes the switch invisible to everyone outside the business.

Keep the original service reports, certificates and defect notices as documents too, attached to the site record, because the signed PDF is still the artefact an assessor or insurer may ask to see. The structured history gives you the continuity; the documents give you the proof.

4. Getting your data out

The data in your current software is your data. Ask for all of it, in a structured form, before you give notice and before anything is switched off. The specific exports to request:

The asset register as a spreadsheet, with every field, not the summary view. Make sure the tag or barcode number column is in it.
The defect register, open and closed, with classifications and dates.
The service history at activity level: asset, routine, date, result, technician.
Every service report, certificate and defect notice as PDF, organised by site.
The client, site and contact lists and whatever holds the contract and billing terms.
Any commissioning or reference figures the system stores, however it stores them.

Do this while the account is in good standing. Most platforms retain data for a period after cancellation, but the export tools are easiest to use while you are still a customer, and a complete export in hand is what makes the rest of the plan calm.

5. Timing the cutover around the cycle

The cycle gives you a natural rhythm to work with. The monthly routines are the busiest and the most forgiving, because the next one is only four weeks away. The yearly and five-yearly routines cluster around each site's anniversary and carry the heaviest reporting.

Three rules follow. First, cut over immediately after a monthly round has been completed and recorded in the old system, so the last-done dates you carry across are fresh and the first thing the new system schedules is the next month's visits. Second, look at the next sixty days of yearly and five-yearly work across the portfolio and move the cutover away from any heavy fortnight. Third, for a business with sites in several states, remember the annual statement deadlines differ, and avoid the month before a cluster of them falls due.

The quietest month of the fire calendar for most businesses is the one they are least inclined to spend on a software project. It is still the right month.

6. The cutover plan, week by week

Week 0: export. Everything in section 4, pulled while the old account is live. Nothing else happens this week.
Week 1: load and reconcile. The asset register, every past reading, open and closed defects, the full service history and the last-done dates go into the new system. Then a site-by-site reconciliation: does every site show the right asset count, does every open defect appear, does every routine show a plausible next-due date. This is the step that catches a stale export or a mapping error, and it is done at a desk, not in the field.
Week 2: the office runs both; the field stays on the old app. The office checks the new system's forward schedule against what the old system says is due, and resolves any difference. Technicians keep working the old app for one more week so that no visit is recorded twice or not at all.
Week 3: the field switches on one day. Not site by site, not technician by technician. One Monday, every technician is on the new app and the old one is read-only. On every first visit under the new system, the technician scans the existing tag on each asset, which confirms the register matches the building. Anything on the wall that is not in the register is added on the spot.
Week 4: the first compliance review. With a full month of real work in the new system, the compliance view across the portfolio is read for the first time. Any gap it shows is either a genuine missed routine or a last-done date that came across wrong. Both are fixed now, eleven months before an assessor would have found them.

Four weeks, one of which is the field team doing exactly what they did before, with a different app in their hand. The dangerous version of a software switch is the one that runs two live systems for a quarter while everyone decides. Decide first, then move once.

7. What to tell building owners

Owners and building managers carry the legal obligation to maintain their essential fire safety measures and to hold the evidence. Their interest in your software change is exactly one question: is my record continuous. The answer should be yes, and it should reach them before they think to ask.

A short note to each client at week 1 is enough. The service history is preserved in full, the schedule continues without interruption, the reports will look different from a given date, and here is how to see your compliance position at any time. For portfolio clients, that last point is the one that turns a software change into a reason to stay with you: an owner of forty buildings who can see all forty on one screen is not going to put the contract out to tender.

8. Bringing the technicians with you

The field team is the part of the switch that worries owners of fire businesses most and causes the least trouble in practice, for a simple reason. A technician's job on site is the same under any software: find the asset, do the routine, record the result, photograph the defect, move on. If the new app makes those five things faster, and works in the basement plant room with no signal, adoption is complete by the end of the first week.

Two things make the difference. The existing asset tags must scan straight into the new app, so nobody is re-tagging a building. And the forms the technician sees must be the forms for that asset type and that routine, so there is nothing to look up. Give the field team a half-day on the app before the switch day, pair the most sceptical technician with the office for the first two days, and the revolt does not happen.

9. How Maintenance Partners runs the migration

Businesses moving to Maintenance Partners do not run this migration alone. Our team does it with you. You send the exports from section 4, and we map and import all of it: the asset register, sites and clients, every past inspection and reading, every defect open and closed, the complete service history and the original service report PDFs, photos and documents, then walk the reconciliation with you site by site before any technician touches the app. We have done this for fire businesses coming off FileMaker-based systems and off Uptick, and in every case the whole record now lives in Maintenance Partners against its asset. Where the outgoing platform allows it, as Uptick does, we pull the data directly with your own access rather than relying on spreadsheet exports. Bringing a business across properly is part of getting you started, not a project we bill for.

Three things about the platform make the cutover clean. The schedule is computed from the last-done dates, so the moment the register is loaded every asset in the portfolio shows its correct next-due date for every routine, and nothing is skipped or double-booked. The compliance view shows the whole portfolio against the standard from day one, so a wrong date in the migration is visible in week 4 instead of at audit. And the field app scans the barcodes and QR tags already on your assets straight to the asset record, so the register is verified in the course of normal work rather than by a separate re-tagging exercise.

If the state of your current software is the thing holding your business back and the history is the reason you have not moved, talk to the team. Bring an export of your asset register and we will show you the migration on your own data.

A note on jurisdiction

This article describes the records and timing that apply under AS 1851 and Australian annual reporting frameworks in general terms. Retention periods, statement deadlines and the records an assessor will ask for vary by state, by asset class section and across editions of the standard. For sign-off on a particular building's record, rely on the current standard and the authority having jurisdiction.