Home services and trades
Switching pest control software: what happens to service history and autopay
By SourceX Editorial · Updated
Short answer
When you switch pest control software, active accounts, recurring schedules, agreements and open balances migrate, while detailed treatment history is usually safest in a read-only archive. Autopay is the riskiest piece: card and bank details normally sit with the payment processor, so enrollments carry over only if the processors can transfer them securely.
Key takeaways
- Treatment and application records are regulated and detailed, so keep the originals intact in a read-only archive.
- Autopay enrollments move only through a secure processor-to-processor transfer or a supported shared processor; otherwise customers re-enroll.
- Termite warranties, bait station maps and inspection graphs often move as attachments only, so check a sample.
- Reconcile the autopay list after cutover: who carried over, who needs a new enrollment, who was missed.
What is at stake in a pest control data conversion#
A pest control data conversion puts three kinds of records at stake: the regulated treatment history, the recurring revenue engine of schedules, agreements and autopay, and the termite records that carry long-term obligations. PestPac, FieldRoutes and other pest control platforms structure these differently, so field names rarely map one to one.
Treatment records hold product names, EPA registration numbers, amounts applied, target pests, application sites and the applicator. Termite files hold inspection graphs, bait station maps, monitoring history and warranty or bond terms. Site notes hold gate codes, pet warnings and access instructions that technicians rely on every visit.
Ask each vendor for a field map before you sign: which source fields land where, which become free-text notes and which are dropped. A field map turns a promise of full conversion into something your office manager can check line by line against real accounts.
Migrate or archive read-only: a record-by-record checklist#
The record-by-record checklist below separates what the new system must run on from what only needs to be kept. Most companies migrate the active layer and archive the full history, so the archive column is rarely empty.
| Record | Migrate | Archive read-only | Watch for |
|---|---|---|---|
| Active customers, sites and contacts | Yes | Yes | Merge duplicates before import |
| Recurring service schedules and routes | Yes | Yes | Frequencies and next due dates |
| Service agreements and renewal dates | Yes | Yes | Pricing and terms carried over correctly |
| Termite warranties and bonds | Active ones | Full history | Original agreements and inspection graphs |
| Bait station maps and monitoring | Station list and last service | Full history | Diagrams arriving only as attachments |
| Treatment and application records | A recent summary, if needed | Full detail | Fields flattened into notes |
| Invoices, payments and balances | Open balances | Full history | Receivables reconciled at cutover |
| Autopay enrollments | Only through a processor transfer | Authorizations and enrollment records | Customers left without a payment method |
| Site notes, photos and signatures | Notes needed in the field | Full history | Long notes cut short |
Why treatment history usually belongs in the archive#
Treatment history usually belongs in the archive because it is detailed, regulated and easy to damage in an import. State pesticide regulators generally require application records to be kept, and the required contents and retention periods vary by state, so check with your state's lead agency rather than relying on the new system's import.
Imports often flatten structured fields such as product, rate and target pest into a single note, which makes the record harder to produce during an inspection or a complaint. Keep the original records intact in the archive, and migrate a short summary of recent treatments per site so technicians have context on their first visit in the new system.
What happens to autopay when you switch#
Autopay depends on where card and bank details are stored, which is usually the payment processor or gateway, not the pest control software itself. The software holds a token that points to the stored card or account. Whether that token keeps working after a switch depends on the processor relationship, not on the software import.
Never move raw card numbers through spreadsheets or email. PCI DSS obligations apply to card data, and any transfer should run directly between processors through their secure process.
Expiring cards add a quieter risk. A card that expires around cutover may have been refreshed by the old processor's card updater but not by the new one, so review upcoming expirations as part of the autopay reconciliation.
| Scenario | What usually happens | What to do |
|---|---|---|
| New software supports your current processor and merchant account | Tokens may keep working once the account is connected | Confirm with both vendors and test a small batch before cutover |
| New software requires a different processor | Tokens move only through a processor-to-processor transfer, if both support it | Request the transfer early and ask which card types and bank drafts are covered |
| No token transfer is possible | Customers must enter payment details again | Plan outreach, a secure enrollment link and staff to handle calls |
| Bank draft (ACH) enrollments | Authorization records matter as much as account details | Keep signed or recorded authorizations in the archive |
A cutover sequence that protects billing#
A cutover sequence that protects billing runs the old system to a clean stop before the new one starts charging. The order matters more than the speed, because a missed or doubled autopay run costs more goodwill than any other conversion mistake.
- Step 1: confirm the token transfer path with both processors and both software vendors in writing.
- Step 2: pause new autopay enrollments in the old system close to cutover.
- Step 3: run the final billing cycle in the old system and export receivables.
- Step 4: import active accounts, schedules, agreements and open balances.
- Step 5: export and archive full history with original account and service IDs.
- Step 6: reconcile the autopay list: carried over, needs re-enrollment, missing.
- Step 7: contact customers who need to re-enroll before their next scheduled charge.
- Step 8: keep the old platform open in read-only mode for as long as the contract allows.
Illustrative: a pest and lawn company changes platforms#
Illustrative: a fictional pest control company with a lawn care division is moving from an older platform to a newer one that requires a different payment processor. The COO learns early that card tokens can transfer between the two processors but bank draft enrollments cannot, so bank draft customers will need new authorizations.
The team migrates active accounts, schedules, agreements, active termite warranties and open balances, and archives every treatment record, inspection graph and bait station history with original IDs. After cutover, the billing lead reconciles the autopay list and finds a group of card customers whose expired cards never transferred; they get a personal call. Treatment records stay in the archive, where the office can produce them for an inspection without touching the new system.
The archive's longer life#
The archive's longer life is as a record of what worked: which treatments were applied at which sites, for which pests, in which seasons, and whether the customer called back for a re-service. Linked that way, pest control history is the kind of field record AI developers building service, routing and diagnostic tools look for.
SourceX evaluates such archives with the SourceX Enterprise Data Value Framework, where domain expertise, human-generated signal and scale raise value while privacy burden and preparation cost weigh on net value. Preparation removes customer names, addresses, gate codes and payment details, and the SourceX Evidence Packet captures provenance, licensing rights and permitted use alongside the privacy record and release authorization for anything approved. Regulated originals stay with you; only prepared copies are licensed.
Frequently asked questions
Will customers notice the software switch?
Many will. Customer portal logins, invoice layouts, text message numbers and sometimes autopay enrollment can change. Send a short notice before cutover explaining what changes and what customers need to do, and give office staff a script for the questions that follow.
Can we keep using the old system read-only?
That depends on your contract and the vendor's offerings. Some vendors allow a reduced read-only subscription for a period; others close access at termination. Read the data return and termination terms before giving notice, and finish your exports first either way.
What happens to open re-service requests?
Migrate open re-services as active work so nothing is missed in the field. Archive closed re-service history alongside the original treatments, because the link between a treatment and a later callback shows whether the treatment worked.
Does the new vendor's conversion include termite graphs?
Ask directly and check a sample. Inspection graphs and bait station diagrams often move as attached files rather than structured data, and some conversions leave them out. Keep the originals in the archive in either case.
Who should own the conversion internally?
The COO usually owns the decision, with the office manager responsible for records, the billing lead for autopay and receivables, and a service manager for schedules and routes. One named owner for each area keeps gaps from falling between them.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.