The fear of migration keeps more agencies on legacy software than the software itself does. In practice the data is smaller and simpler than anyone expects.
Step 1 — Export everything you can
Pull the asset inventory, all condition and inspection history, completed work records and any attachments. Get it in open formats: CSV, shapefile, geodatabase, GeoJSON.
Confirm your contract terms on data ownership and export before you give notice — the time to discover an export restriction is not during the transition.
Step 2 — Decide what actually comes across
Not all of it should. Legacy systems accumulate abandoned asset classes, duplicate records and fields nobody has filled in for years.
A useful rule: migrate anything with a date, a condition or a cost attached. Archive the rest to a file share so it exists if anyone asks.
Step 3 — Map fields and validate a sample
Map source fields to the new data model, including condition scales, which rarely match one-to-one. Then pick 20 to 30 representative assets and check them field by field against the source system.
If the sample is clean, the bulk load will be. If it is not, fix the mapping before loading the full dataset.
Step 4 — Run parallel, then cut over
Keep read access to the legacy system for one cycle while crews work in the new one. Once a full inspection or work cycle has been completed in the new platform without needing the old one, cut over.
AtlasView includes data migration support in every plan, and typical agency setup takes about five days from data handover to go-live.
Frequently asked questions
- Will we lose our inspection history?
- No, provided you can export it. Historical condition scores and inspection dates import alongside the asset inventory and remain queryable.
- What if our legacy data is messy?
- Messy data is normal. Load it, then correct records as inspections and work touch each asset. Waiting for clean data is the most common reason migrations stall.