The destination architecture matters — pick the EU AI Act + DPDP-ready landing zone
Migration only pays off if the new platform clears the 2026 compliance bar. Start with the landing-zone read before you write the export plan.
See the EU AI Act-ready landing zoneWhy this migration is harder in 2026
Switching off screenshot monitoring used to be a feature-swap conversation. In 2026 it's a regulatory deadline conversation. The EU AI Act's high-risk obligations land on August 2; the DPDP Rules notification window in India is open. A migration that drifts past July risks running the cutover under the new regime — new consent surface, new audit trail format, new deployer kit obligation — instead of finishing under the old one. The 12 points below are designed to land the cutover before that window closes.
Hubstaff and Time Doctor share enough architectural DNA that the checklist applies to both with small per-vendor notes. Where the two diverge in export format, retention defaults, or invoice-rate mapping, the per-vendor note calls it out.
The 12-point migration checklist
Phase 1 — Data export and audit (weeks 1-2)
- Pull a full audit data export from the source system. Hubstaff: Reports → Detailed exports plus the API for any custom fields. Time Doctor: Account → Data Export → full workspace dump. Export at minimum 12 months of activity logs, screenshot archive if your retention policy requires it, timesheet records with approval state, project / client mapping, user roster, and invoice / billing-rate history. Pull twice — once at the start of the parallel run and once on the cutover date.
- Identify the audit-retention obligation and pin export format. Some jurisdictions and client contracts require multi-year retention. Decide before cutover whether the old system stays in read-only paid tier for the retention window or whether the export sits on cold storage with a documented retrieval SLA. Cold-storage with a one-week retrieval SLA is usually the cheaper path; counsel decides.
- Map every custom field and integration. Slack, Jira, Asana, GitHub, payroll engine, invoicing tool — list every integration the source system writes to or reads from. Cutting one integration mid-migration is the single most common cause of an invoice or payroll discrepancy. The list of integrations is the test plan for Phase 2.
Phase 2 — Parallel run and reconciliation (weeks 2-4)
- Run both systems in parallel for 2-6 weeks. Team under 50: 2 weeks. 50-200: 3-4 weeks. 200+ or any billable-client time: 4-6 weeks. The parallel run isn't about catching technical bugs — it's the only window where you can verify payroll, invoicing, and management reporting tie out on the new platform before the old one is switched off.
- Reconcile timesheets daily for the first week, weekly thereafter. Pull the same date range from both systems. The discrepancies in week 1 usually trace to one of three things: time-zone misalignment, project-mapping gaps, or a user whose old-system permissions didn't migrate cleanly. Fix the root cause, don't paper over the variance.
- Run a payroll dry-run on the new system. Take a real timesheet week, run it through the new tool's export to your payroll engine (Keka, Gusto, RazorpayX, ADP), and reconcile to the rupee or cent against the old system's payroll output. Any discrepancy over 0.5% is a stop-cutover signal — trace it before scheduling go-live.
- Freeze billing-rate and project mapping for the parallel run. Any rate change or project re-mapping mid-parallel-run makes reconciliation impossible. Pin rates as of the parallel-run start date, queue any rate changes for the first week post-cutover.
Phase 3 — Employee notice and consent (weeks 3-4)
- Issue written notice at least 14 days before cutover. Plain language. What the new tool captures. What it does not. What the old tool captured that the new tool will not. A contact for questions. EU workforce: add the GDPR Article 13 transparency notice and any works-council consultation required by national law. India workforce: document the consent record per data principal under DPDP Section 4. Skipping notice is the largest source of legal exposure in any monitoring switch.
- Reset surveillance defaults at the org level. Whatever the new platform's surveillance defaults are, set them at the organisation level before any user logs in. If the new platform ships screenshots off by default, leave it off and turn on per-role only where the business case is documented. If the new platform inherits the old defaults via API import, override at the org level. Surveillance default-on is the most expensive mistake to undo post-cutover — trust loss compounds.
Phase 4 — Cutover and decommission (week 5-6)
- Schedule cutover for the first day of a payroll cycle. Never cut over mid-cycle. Schedule the cutover for the start of a new cycle so all timesheet approvals close cleanly on the old system, and the new system starts the cycle with a clean record. Pre-communicate the cutover date 7 days out and on the day.
- Keep the old system read-only for at least 30 days. Don't delete the source data on cutover day. Move the old system to read-only (Hubstaff: downgrade to free tier; Time Doctor: downgrade to lowest paid tier with export retained) for 30 days so any post-cutover audit query has the data to answer it. Then archive per the retention obligation set in step 2.
- Decommission desktop agents and write the post-mortem. Uninstall the source-system desktop agent at the end of the read-only window. Write a 1-page migration post-mortem — data discrepancies caught, payroll variance, employee questions raised, surveillance-default reset confirmation. Attach to the procurement file for the next vendor review.
Where teams usually land — brief gStride read
For most teams running this checklist in 2026, the destination is a platform that clears the EU AI Act high-risk bar by design rather than by configuration. gStride was built around the capture / inference split the Act effectively mandates — surveillance off by default, AI framed as recommendation to a human, deployer kit shipped with the product, audit trail exportable in under 30 minutes. The full migration playbook from Hubstaff / Time Doctor / Keka into gStride is in our 5-phase migration playbook. The architectural read is in our EU AI Act-ready solution stance.
Other destinations work for narrower use cases — Toggl Track for solo billers, Keka for HR-suite-only teams. The checklist above applies regardless of where you land.
The compliance overlay
If your team has EU footprint, run the destination vendor through the EU AI Act 7-vendor scorecard before you write the export plan — a Halt-grade destination undoes the whole migration. If India footprint, run the DPDP vendor risk matrix. If both, run both and take the lower verdict band.
5 common migration failure modes — and the fix
| Failure mode | Where it surfaces | Upstream fix |
|---|---|---|
| Payroll variance week 1 | Finance flags 2-8% timesheet delta vs old system | Step 6 — payroll dry-run during parallel run |
| Invoice rate broken | Client invoice goes out at wrong rate post-cutover | Step 7 — freeze billing-rate during parallel run |
| Employee notice complaint | Works-council or grievance filed week 2 | Step 8 — written notice 14 days pre-cutover, plain language |
| Surveillance default carries over | New platform inherits screenshots-on from import | Step 9 — reset defaults at org level pre-user-login |
| Lost audit trail | Counsel asks for Q1 data, source system was deleted on cutover | Steps 2 and 11 — retention plan, read-only for 30 days |
Need the full set of buyer resources?
Migration playbook, vendor scorecards, RFP templates, DPIA templates, deployer kits — everything in one place. No card, no email gate on most assets.
Open the resources hub Read the 5-phase migration playbookFrequently asked questions
What data should I export from Hubstaff or Time Doctor before switching?
Export at least: full activity logs for the last 12 months (or whatever your audit retention requires), project and client mapping, user roster with role and team assignments, timesheet records with approval state, screenshot archive (if your jurisdiction or contract requires retention), invoice and billing-rate history, and any custom-field mappings used by payroll or finance. Both Hubstaff and Time Doctor provide CSV / JSON exports per workspace; Hubstaff additionally has an API endpoint for bulk programmatic export. Pull the export twice — once early in the parallel-run period and once on the cutover date — so the audit trail has both anchors.
How long should the parallel-run period be?
For a team under 50 users, plan a 2-week parallel run. For 50-200, plan 3-4 weeks. For 200+ or any team with billable-client time, plan 4-6 weeks. The parallel run isn't just about catching data discrepancies — it's the only window where you can quietly verify that payroll, invoicing, and management reporting tie out on the new platform before the old one is switched off. Cutover before the parallel run completes is the most common migration failure pattern, and it almost always shows up as a payroll discrepancy in week 1 post-cutover.
What employee notice is required for a switch?
Notice requirements depend on jurisdiction, but the baseline is: written notice to every affected employee at least 14 days before the new platform goes live, plain-language description of what data the new tool captures and what it does not, an explicit note on what the old tool captured that the new tool will not, and a contact for questions. For EU workforce, add the GDPR Article 13 transparency notice and any works-council consultation required by national law. For India deployments, document the consent record per data principal under DPDP Section 4. Skipping notice is the largest source of legal exposure in any monitoring-tool switch.
How do I keep payroll running through a Hubstaff or Time Doctor migration?
Three principles. First, never cut over mid-payroll-cycle — schedule the cutover for the first day of a new cycle so all timesheet approvals close on the old system. Second, run a payroll dry-run on the new platform during the parallel-run period using real timesheet data and reconcile to the rupee or cent against the old system. Third, freeze billing-rate and project mapping for 30 days post-cutover so any discrepancy traces to data capture rather than rate changes. If your payroll engine sits on a separate platform (Keka, Gusto, RazorpayX), confirm the new productivity tool exports in the format the payroll engine expects before any user is migrated.
What changes for employees post-switch from screenshot tracking?
Three things change visibly. Screenshots stop being captured (or, if you keep a screenshot tool for a specific role like billable client work, the default switches to off and screenshots become opt-in per session). The desktop agent footprint shrinks because the new tool captures fewer surfaces. The productivity-signal layer changes from raw activity score to focus and outcome signals that employees can inspect themselves. Manager workflow changes too — instead of pulling a daily activity report, managers get a weekly or fortnightly outcome view that flags the cases worth a 1:1 conversation. The trust dividend usually shows up in week 3-4 as visible adoption.
This article describes a 12-point migration checklist for teams switching from Hubstaff or Time Doctor in 2026, with notes on the EU AI Act August 2, 2026 high-risk-system enforcement runway and the DPDP Rules notification window expected late 2025 through 2026. Vendor export formats, retention defaults, and integration availability change — verify current source-vendor documentation before pulling the export. Notice and consent obligations vary by jurisdiction; verify with counsel for your specific workforce footprint. The checklist is a buyer aid, not legal advice.