A successful time-tracking migration should preserve the meaning of your records, not just move rows. Before you close a Harvest workflow, check that people, projects, hours and billing treatment still tell the same story in Time Trakkr.
The migration itself imports setup data and then historical entries. The operational work is deciding where the old record ends, where the new one begins and how you will prove that the result is complete.
Define the boundary before importing
Choose a cutover date and an owner. Tell the team which system receives new time from that point onward. Keep a record of any exceptions, such as late corrections to the previous month.
Take source exports and save the reports used for comparison. Use an exact date range, project scope and billable filter. Comparing “last month” in one system with “last 30 days” in another can manufacture a discrepancy even when the imported entries are correct.
Start with a representative period: a completed billing cycle containing active and archived projects, several people and both billable and non-billable work.
Run the documented import sequence
In Time Trakkr, an admin connects the Harvest migration using the account ID and personal access token, imports clients, projects, tasks and people, then backfills time entries. The optional “only before” date controls the historical boundary.
Active people arrive as invited members; archived people remain disabled with history attached. Check email matching before inviting the team. See the Harvest migration guide for the current steps and re-import behavior.
Keep credentials out of migration spreadsheets and client reports. The reconciliation file needs source identifiers and results, not access tokens.
Compare totals in layers
Use a control table rather than checking only the grand total. This illustrative example shows why:
| Control | Harvest | Imported result | Difference |
|---|---|---|---|
| Project Alder hours | 80 | 78 | −2 |
| Project Birch hours | 45 | 47 | +2 |
| Total hours | 125 | 125 | 0 |
The total matches while two projects disagree. Investigate project mapping and entry allocation before accepting the migration.
Compare by month, project and person. Add billable status and relevant task groups where they affect reporting. Check entry counts alongside hours: two missing entries can be concealed by one duplicated entry with the same total duration.
Record each exception with the source entry or report reference, expected result, observed result and resolution. Preserve the explanation even when the correction is small.
Check money separately from hours
Correct hours do not guarantee correct amounts. Review the applicable rates, currencies, historical changes and billing status for a sample of entries.
Pick at least one completed invoice period and one open period. Confirm that work already charged to a client is not accidentally eligible for another invoice. Preserve the original invoices and payment records; imported time is not a replacement for those commercial documents.
If a difference comes from a rate or rounding rule, resolve that rule. Do not alter accurate durations to force the money total to match.
Review historical people and edits
An archived contributor may no longer need access, but their time still belongs in the project record. Include former team members in the historical comparison while keeping current access limited to the people who need it.
Also inspect records changed after the first import. A renamed project or corrected rate can create a legitimate difference between systems. Decide which value should govern and document it. Do not assume a second import will automatically make every field identical.
Close with explicit acceptance
Before the team fully switches, have the migration owner confirm that the control period reconciles, unresolved exceptions have owners, the cutover boundary is clear and the next billing cycle can be produced accurately.
Retain source exports according to your normal records policy. During the first live cycle, compare the time report and draft invoice again. That final check catches workflow problems that a historical import test cannot expose.
Use the switch-from-Harvest overview for the transition and the reconciliation checklist here to validate the result.
Common questions
Is a matching total enough?
No. The same total can hide project, person or billable-status errors. Compare meaningful subdivisions and representative entries.
Should we erase historical differences by editing imported hours?
Only correct a duration when the duration itself is wrong. Rate, mapping and billing-status problems need their own corrections and a documented reason.
