CAD/MDT Migration: Moving Systems Without Losing Your Community

The decision is made. You are moving to a different system, and now you have to do it without dropping forty people and eight months of records on the way.

Most of the damage in a CAD/MDT migration does not come from the data. It comes from the two weeks where nobody is sure which system is real, so half your officers stop filing anything and the habit never comes back.

The sequence below fixes that. It takes about two weeks of calendar time and roughly four hours of actual work.

What Does a CAD/MDT Migration Actually Move?

A CAD/MDT migration moves three separate things: your roster (people, ranks, departments, callsigns), your records (citizens, vehicles, warrants, citations, reports), and your configuration (priority tiers, unit types, permission structure). The roster and configuration are rebuilt by hand in under an hour. Only the records need a real export and import.

The roster is smaller than you think

You are not moving four hundred people. You are moving the ones who played this month.

Pull your activity data before you start and migrate active members only. Everyone else gets added on their next login. A migration is the cheapest inactivity sweep you will ever run, and starting clean beats importing three years of accounts that never come back.

Configuration is a rewrite, not a transfer

Priority tiers, unit types, and rank permissions almost never survive between systems, because no two products model them identically. Do not fight this.

Write your four or five rank tiers fresh on the new system, which is a twenty minute job and a good moment to delete the bespoke permission set someone made for one person in 2024. The community administration guide covers how to structure tiers so they stay small.

Records are the only real dependency

Citizens, vehicles, warrants, and reports are the part with history in it. That is what an export exists for, and it is the one thing you cannot rebuild by typing faster.

How Do You Migrate Without Losing Your Roster?

Week one: build it empty and leave it alone

Set up the new system with departments, ranks, and configuration. Do not invite anyone. Do not import anything.

Give logins to three people you trust and ask them to run one patrol on it, in parallel with the live system, filing everything twice for a single night. Two hours of that surfaces every disagreement between how the old system worked and how the new one does, while it is still cheap to change.

Week two: import records, then announce a date

Import your records and spot check twenty of them by hand. Open a warrant, open the person it belongs to, open a report that references both. If those three jumps work, the import worked.

Then announce a single cutover date and time. Not a transition period. A date.

Cut over on your busiest patrol night

This feels wrong and it is correct. Cutting over on a quiet Tuesday means nine people learn the new system and thirty do not, and those thirty arrive on Friday to something unfamiliar with nobody around who knows it.

Cut over when your community is fully staffed and your supervisors are online. Everyone learns it together, in one night, with help present. Make the old system read only that same evening so there is no ambiguity about which one is real.

The Export Question You Should Have Asked First

What a usable export looks like

A usable export is a machine readable file you can open yourself, containing your records with their relationships intact. A citizen file that has lost its link to the vehicles and warrants attached to it is a list of names, not a record set.

Ask three questions of any system before you commit to it: what formats does data export produce, does it include audit history, and can you run it yourself without opening a support ticket. The selection checklist covers what else is cheap to test before signing up.

When there is no export at all

It happens, and it is survivable.

Migrate the records that are still live and let the rest go. Open warrants, active characters, anything referenced in the last sixty days. Retype them or copy them across during your parallel week. A community of forty rarely has more than a hundred live records, and two people can move that in an evening.

Archive the old system as a screenshot set or a browser export if you can, then stop paying for it. Historical records nobody has opened in six months are not worth a monthly fee.

What to Fix While You Have the Chance

A migration is the only moment your community accepts change without arguing, so spend it.

Consolidate the roster that currently lives in Discord roles, a spreadsheet, and a game server whitelist into one place. Turn on an audit log of edits and deletions if you did not have one. Set your priority tiers properly rather than importing whatever the old defaults were.

Fix the dispatcher gap while you are here. If your queue depended on somebody volunteering to sort it, it mostly went unsorted. PlateNet CAD/MDT routes calls to available units automatically, orders them by priority, and flags units that have sat in one status too long so the queue skips them, which the automatic dispatch guide explains in detail.

The migrations that go badly are the ones that try to reproduce the old system exactly. You are not restoring a backup. You are moving a community, and it will land better if you arrive with the two or three things that were annoying already fixed.

Frequently Asked Questions

How long does a CAD/MDT migration take?

About two weeks of calendar time and four hours of work. One week to build and test the new system in parallel, one week to import records and cut over. Communities that stretch this across a month lose members to the confusion rather than to the software.

Can I move my records between CAD systems?

Only if your current system offers data export. Check the format and whether relationships between citizens, vehicles, and warrants survive it. If there is no export, migrate live records by hand and archive the rest.

Will I lose my roster when switching CAD systems?

Not the people, if you cut over on one announced date with supervisors online. Roster data itself is quick to rebuild, and migrating active members only is better than importing years of dormant accounts.

Should I run two CAD systems at once during a migration?

For one night, with three testers, yes. For two weeks with your whole community, no. An extended overlap means nobody knows which system is real and record keeping stops on both.

What should I fix during a migration?

Consolidate the roster into one place, turn on audit logging for edits and deletions, and set priority tiers deliberately. A migration is the one moment a community accepts process changes without pushback.

Do I need to migrate at all if my community is small?

Under about twenty five active members, moving is cheap enough that the question is only whether the new system is better. Past a hundred members with real history, plan the sequence properly and confirm export first. Start with what a CAD/MDT system is if you are still deciding.