How to move from RoadBotics to RoadScout: a technical migration guide

Agencies that chose RoadBotics a few years ago bought into a genuinely novel idea for its time: that road-condition data should flow from ordinary fleet vehicles, not from specialised survey vans. That idea is now the standard. The question five years on is what the next generation of that standard looks like: continuous vs periodic collection, telemetry-plus-vision vs vision-only, first-class API integration vs screenshot-driven reporting. Increasingly, we are asked to help agencies migrate.

This is a practical walkthrough of that migration. It is not a pitch document. The decision tree below is honest about when migration makes sense and when it doesn't.

When migration makes sense

1. You want continuous collection. If your RoadBotics contract has been structured as a periodic drive-survey (every 12 to 24 months), and you now need weekly or monthly condition updates, the economics of drive-survey collection don't scale. Continuous smartphone capture on fleet vehicles you already run fixes that: on a per-km basis it is typically 40–70% lower while updating 10–50× more often.
2. You need a richer data model. RoadBotics is primarily an imagery pipeline. If your workflow needs IMU-derived signals such as corrugation intensity, grade, lane-line analysis, or a ride-quality-indexed IRI estimate, an imagery-only system leaves half the evidence on the table.
3. You want first-class API integration. Modern asset-management systems and GIS workflows need more than a CSV export. If you are building automations on top of your condition data, a REST API with webhooks, GeoJSON output and granular event-level access matters.

If none of the above applies and your program is well served by a periodic RoadBotics update, there's no reason to migrate. The rest of this guide is for teams that have already decided they want to.

What to export from RoadBotics

Ask your account manager for a complete historical export. The specific artifacts that matter for migration:

• Segment-level condition scores (PCI or the RoadBotics-specific rating, with the date each score was produced).
• Detection events with latitude / longitude, defect type, severity and the evidence image URL.
• Asset inventory (signs, markings, manholes) if you ran the asset module.
• Work-order history if you were using the workflow features.
• Image archive. This is the one most often forgotten in a vendor change. Get the raw evidence frames, not just URLs that will stop resolving once the contract ends.

RoadBotics' standard export produces CSV and KML. Our import tooling accepts both, plus Shapefile and GeoJSON if you have a GIS export ready.

Data model translation

The translation is usually straightforward, with three edge cases:

Condition score alignment

If your RoadBotics program scored to ASTM D6433, the translation is direct: RoadScout scores to the same standard and the historical trend line is continuous. If you used the RoadBotics-specific 1–5 rating, we apply a per-agency calibration against a small sample of segments inspected by both systems in the first fortnight of parallel operation. The calibration is published, so the agency owns the reconciliation, not the vendor.

Severity banding

ASTM D6433 severity is low / medium / high. Most agencies sit fine with that. If your internal workflow uses a different banding (1–3, 1–5, or a custom scheme), we map on import and preserve the original value in a side field for audit.

Coordinate drift

Older RoadBotics exports sometimes show sub-10 m coordinate drift from consumer GPS. RoadScout consolidates nearby detections (10 m clustering) and runs a one-time geospatial alignment during import so historical detections snap to the current network centreline. No data is lost: the pre-alignment coordinates stay in a side field.

The cutover

We run every migration in the same four-week shape. Most agencies finish the first three weeks and then park in parallel operation for as long as they want.

1. Week 1: export and import. RoadBotics export landed, imported to RoadScout, archive layer visible on the dashboard. Historical segment scores plotted on the network map.
2. Week 2: capture deployment. Deploy the RoadScout app to fleet vehicles you already run. No new hardware. Operators run their normal routes for seven days; data flows to the cloud and runs through the inference pipeline automatically.
3. Week 3: first refresh. Prospective condition scores and detections from RoadScout appear on the dashboard, overlaid on the historical RoadBotics archive. Agency engineers review and accept or decline the first batch.
4. Week 4 onwards: parallel operation. If RoadBotics is still running, it runs alongside for as long as the agency wants, with both systems visible on the dashboard. Most agencies end parallel operation at 2 to 3 months, when confidence in the new pipeline is settled.

The question you should ask your procurement team

Most migrations we do are driven not by dissatisfaction with RoadBotics but by a procurement cycle asking one question: what is the cheapest way to keep doing this? The answer, for most agencies with an existing fleet, is smartphone capture on those fleet vehicles, inference on modern compute, and an API-first platform. The migration cost is typically one quarter of the annual saving.

If you want, we can scope a specific migration against your current contract. Tell us the network size and which RoadBotics modules you run, and we'll produce a technical migration plan inside 48 hours.