When moving from Toggl Track to Time Trakkr, check how the destination represents your projects, task-less entries and billing rates before judging the imported reports. The same hours can be present while the categories around them look different.
A short mapping review makes those differences explainable. It also identifies which records need separate preservation rather than an assumption that every field moves automatically.
Create a mapping sheet before the import
List the source workspace, client, project, task conventions and rate structure. Choose a few examples that represent the awkward parts of your setup: a project without a client, an entry without a task, a former team member and a project with a special rate.
Record the expected destination for each example. This becomes your acceptance checklist rather than a new operational database.
| Source situation | Question to resolve |
|---|---|
| Project without a client | Where will it appear in client reports? |
| Entry without a task | Which destination task will hold it? |
| Project-specific rate | Which rate should apply after import? |
| Inactive contributor | Is their historical effort still attributed? |
| Tags used for reporting | How will that reporting dimension be preserved? |
Understand the documented mappings
Time Trakkr’s Toggl importer connects to a selected workspace, imports setup data and then backfills history. Projects without a client are placed under “(No client),” and task-less entries use a “Tracked time” task. Project rates and per-person project rates have different mappings. Inactive people retain historical attribution, while active people need invitations before signing in.
Entry tags are not imported, so preserve any tag-based reporting you need separately. Consult the Toggl migration documentation for the complete current behavior rather than assuming every source field has a destination equivalent.
Keep a historical mapping separate from a future cleanup
Suppose a project contains 120 hours, including 35 hours with no source task. After migration, the hours may be intact but grouped under a destination fallback task.
That can be the correct import result. It is different from a decision to retrospectively label the 35 hours as design or development. Do not invent detail that the original records never contained.
You can introduce clearer categories for future work. Mark the change date so a report comparing old and new periods does not imply that the categories were always identical. Preserve the original descriptions when making justified corrections.
Reconcile duration and money independently
Select a completed period and compare total hours by person and project. Then inspect representative entries, including the unusual cases from the mapping sheet.
For a simple hourly example, six eligible hours at an agreed $140 rate imply $840 before other adjustments. If both systems show six hours but different amounts, check rate selection and currency before investigating duration.
A rate table may have changed since the original work was delivered. Historical invoices remain valuable evidence of what was actually charged. Do not assume that a newly calculated report recreates every historical commercial decision.
Control the cutover boundary
Choose when people stop adding ordinary entries in Toggl and start recording new work in Time Trakkr. Align the import boundary with that decision. If someone needs to correct older work, record where the correction belongs and whether a re-import is required.
The documentation describes an “only before” date for backfill. Review that value intentionally. Importing everything into a workspace that already contains overlapping manually entered history needs extra reconciliation, even when the importer recognizes its own previously imported entries.
Test the first real reporting cycle
After the historical comparison, produce the report you actually use to run the business: a client breakdown, weekly team review or draft invoice. Check whether former tags, task conventions or rate assumptions were essential to that output.
If something is missing, choose an explicit remedy: retain an archive, revise the report or configure future data collection. Avoid quietly dropping a dimension simply because the new report looks cleaner.
When the mapping and totals are accepted, invite the active team and keep a named owner for migration questions. The switch-from-Toggl overview provides the commercial context; this mapping process provides the evidence that the transition worked.
Common questions
Should we rename every project during migration?
Keep migration validation and optional cleanup separate. Stable names or identifiers make differences easier to investigate.
Does the same total prove the categories are right?
No. Check task-less entries, missing clients and rate exceptions individually. Those mappings determine whether the report remains useful.
