Leaving Tenstreet Without Losing Ten Years of Driver History

Ask a recruiting manager why they are still on a platform they complain about weekly and you will rarely hear a feature reason. You will hear a version of this: everything is in there. Ten years of applications. Notes from recruiters who left in 2019. Which drivers were rejected and why. Who reapplied twice. Who was terminated and must never be re-hired.

That history is the switching cost, and most migration plans underestimate it badly.

TL;DR

• The blocker is not the software, it is the record history and the institutional memory inside it.
• Migrate ownership and notes, not just names and phone numbers.
• Rejection and termination history is a compliance asset, not archive material.
• Run both systems in parallel for one recruiting cycle. Do not cut over on a Monday.

What a lead export actually contains

A standard export gives you name, phone, email, source, and a status. That is roughly a fifth of what makes the old system useful.

What is usually missing, and what you have to ask for specifically:

• Recruiter notes with their timestamps and authors. "Called, no answer, will retry Friday" from a named recruiter on a dated line is the difference between a warm record and a cold one.
• Contact ownership as it was. Which recruiter owned which record, including recruiters who no longer work there.
• Status history. Not the current status — the path. A driver who went new to interview to rejected reads very differently from one who has been sitting in new for two years.
• Rejection reasons. Especially disqualifying ones.
• Reapplication history. Carriers with a reapply window need to know when somebody last applied.
• Original traffic source at the level it was captured. Paid social, organic, referral, offline.

If the export cannot produce these, that is worth knowing before you sign anything, not after.

The records that are not just history

Three categories are operational the moment they land.

Do-not-hire. Terminated drivers, drivers who failed a drug and alcohol screen, drivers with a disqualifying violation. If this does not survive the migration, your recruiters will re-work those records within a month and somebody will get an offer they should never have received.

Reapply windows. Many carriers have a rule about how soon a rejected applicant may reapply. That rule is unenforceable without the date of the last application.

Consent and disclosure records. Anything tied to a background check the driver signed for. That paperwork has retention obligations independent of which vendor stores it.

Treat these three as blocking requirements for the migration, not as a later phase.

Ownership is the part everybody gets wrong

Here is a scenario that plays out on nearly every migration.

A recruiter left the company two years ago. Their name is on a thousand records. During import, somebody decides that since they no longer work there, those records should be reassigned to the active team.

Two things break at once. The historical record — who actually worked that driver, and when — is destroyed and cannot be recovered. And a thousand cold, ancient records land in active recruiters' queues, where they either get worked pointlessly or trained to be ignored.

The right handling separates two different fields: who owned this historically and who is responsible for it now. Keep the first exactly as it was. Leave the second empty and decide deliberately which records deserve a live owner. Most of them do not.

A migration sequence that works

1. Export everything before you give notice. Access and cooperation are better while you are a customer.
2. Import into a staging state first. Nothing routes to recruiters, nothing triggers automation, no message goes out.
3. Verify counts against the source. Not approximately — record by record on totals per status, per year, per recruiter. Import tools silently cap at a page limit more often than anyone expects.
4. Import notes and status history second, once records exist to attach them to.
5. Turn off automation for imported records. A follow-up sequence firing on a lead from 2021 is a live embarrassment and, if they opted out at some point, a compliance problem.
6. Run parallel for one full recruiting cycle. New leads into the new system, old work finished in the old one. A hard cutover in the middle of a hiring push is how carriers end up back where they started.
7. Only then cancel. Keep a full export archived regardless.

Two checks that catch most problems

Reconcile the totals. If the source says 23,600 records and the destination says 23,000, do not proceed until you know which 600 and why. A round shortfall usually means an API row cap somewhere in the pipeline, not deletions.

Spot-check five records end to end. Pick a rejected driver, a terminated driver, an active driver, a driver with a long note history, and one owned by a departed recruiter. Open each in both systems side by side. This finds more problems in twenty minutes than any summary report.

What good looks like afterwards

You should be able to search a driver's phone number and see everything: every application, every note with its author and date, every status they passed through, why they were rejected in 2022, and which campaign brought them back in 2026.

That is the standard to hold a migration to, because that is what you were paying the old vendor for.

Fleegital imports leads, contact ownership and recruiter note history together, preserving who worked a driver and when — so the record you rely on comes with you rather than being left behind.

Key takeaways

• Names and phone numbers are the easy fifth of a migration. Notes, ownership and status history are the rest.
• Do-not-hire, reapply windows and signed consent records are blocking requirements, not nice-to-haves.
• Preserve historical ownership as its own field. Do not overwrite it with current assignment.
• Import quiet: no automation, no routing, nothing sent, until counts reconcile.
• Run parallel for one full recruiting cycle before cancelling anything.