Version 2.0 replaced the old storage model (leads saved as hidden WordPress posts, keyed on IP address) with fast custom database tables and visitor-ID-based attribution. Existing data is migrated automatically — this page explains what happens.
What changes in 2.0
| Version 1.x | Version 2.0 | |
|---|---|---|
| Storage | Hidden custom posts | Dedicated indexed database tables |
| Lead identity | IP address | Random first-party visitor ID |
| Returning visitor | Overwrote the previous UTM data | First touch kept + last touch updated |
| IP handling | Stored raw | Salted hash only (or nothing) |
| Capture method | PHP during page load | Deferred browser beacon (cache-proof) |
| Journey history | None | Every page view recorded |
How the automatic migration works
- When you update to 2.0, a background task is scheduled immediately.
- It processes your legacy leads in batches of 30, once per minute, so even large datasets migrate without straining the server.
- Each legacy lead becomes a lead row in the new tables: its UTM values, original capture date, and a hashed version of its stored IP are carried over, and a synthetic visitor ID is assigned.
- Once the new record is confirmed written, the legacy entry is deleted — your database ends up fully clean, with no leftover data from the old storage format. If a record ever fails to migrate, the original is kept (and skipped on later runs) so nothing is lost.
- When every lead is processed, the background task unschedules itself and the old storage system is retired automatically.
You don’t need to do anything. With a few hundred leads the migration completes within minutes; tens of thousands of leads take proportionally longer, arriving in the Leads screen as they’re processed.
What carries over — and what can’t
Carried over: every enabled UTM value, original first/last-seen dates, one journey entry per legacy lead.
Not reconstructable: legacy versions never stored landing pages, referrers, or per-page journeys, so migrated leads start with a minimal history. Their journeys grow normally from the moment they revisit your site. Because 1.x deduplicated by IP, one migrated lead may historically have represented several people behind a shared network — new tracking won’t have this problem.
Back up before updating
The migration is one-way: once a legacy record has been safely copied into the new tables, the original is deleted to keep your database clean. Downgrading to 1.x after the migration will not bring the old-format data back.
We therefore recommend taking a database backup before updating — standard practice for any major plugin update. The migration itself is safe by design (an original is only ever deleted after its replacement is confirmed written, and failed records are kept, never dropped), but a backup gives you a way back if you decide 2.0 isn’t for you.
Verifying the migration
- Note your lead count under 1.x before updating.
- After updating, give the background task a few minutes (or longer for large datasets).
- Compare the total on the UTM Manager dashboard — it should meet or exceed the old count (new visitors are being tracked simultaneously).
If migrated leads don’t appear, see Troubleshooting — background tasks rely on WP-Cron, which some hosts disable.