Skip to content
TTrackTimer
All articles

Migration guides

Moving from Toggl Track? A practical migration guide

Considering a Toggl Track alternative after Toggl 2.0? Review community feedback, protect your history, and understand what TrackTimer imports.

By · · 8 min read

An analog stopwatch beside project cards connected by an orange thread

If you are considering leaving Toggl Track, start by separating two decisions: whether your current workflow still works, and whether another tool can carry over the information you need. An announcement about a new product is a reason to evaluate those questions, not a deadline to move.

TrackTimer can import clients and active projects from Toggl Track and help you review team access. It does not import historical time entries. If you need all your old and new time records in one application, this importer does not meet that requirement today. This guide explains how to evaluate a switch with that limitation in view.

TrackTimer publishes this guide and is one of the alternatives discussed. Sources were reviewed on September 14, 2026. The community examples below are selected public reports, not a survey, a measure of how common a problem is, or a hands-on benchmark.

Do you have to move to Toggl 2.0?

No. Toggl's official FAQ says Toggl Track remains supported and developed, with no announced sunset date or forced migration. Toggl 2.0 is the renamed Toggl Focus product. Staying with Track is a valid option if it still fits your work. Read Toggl's explanation for Track users.

Be precise about the destination when reading migration instructions. Moving from Track to Toggl 2.0 and moving from Track to TrackTimer are different processes. Toggl documents its own import and live-sync options; those are not capabilities of TrackTimer's importer. Toggl's migration guide and live-sync documentation explain that a one-time import and synchronization of later changes serve different purposes.

What people are saying, and what to learn from it

The most useful community feedback describes a specific workflow. “Can I produce the same client report?” is a better migration test than a general judgment that one product is better. Recent discussions suggest four things to check.

1. More features do not automatically make a better fit

In the June 2026 launch discussion, one user welcomed being able to stay on Track because the new product did more than they needed. Another reported successfully importing tracked data and said most things worked, while asking about charts and tags. An August reply noted that entry descriptions, questioned earlier in the thread, were now visible. That mix matters: a launch complaint may describe an earlier version, and another person's successful move may still leave your particular workflow untested. Read the launch discussion.

Write down the smallest workflow you need: start a timer, choose a project, add a recognizable description, and review the result. Then test the reporting and billing steps that follow. Additional planning features are useful only if they help your team do its work.

2. Understand which product and app hold your records

On September 9, a user reported that recent iPhone entries were not appearing after moving to 2.0. Later that day, the same user said the historical and new iPhone entries were visible after switching back to Track. This supports checking the source application before concluding that data is lost; it does not establish that records were deleted. Read the synchronization thread.

Before a switch, list every place you track time: browser, desktop app, phone, extension, or integration. Record which service each writes to. After the switch, create one short test entry from each tool you intend to keep using and verify its destination.

3. Test your actual export, not just an export button

A September 9 post reported difficulty obtaining CSV data for client billing in Toggl 2.0. On September 10, its author marked the issue solved and thanked the team for its responsiveness. It would be misleading to cite that thread as evidence that CSV export is currently unavailable. Its practical lesson is to test the report your billing process consumes. Read the export discussion and resolution.

Choose a completed reporting period. Check dates, descriptions, project names, billable status, durations, and any fields your downstream process requires. A file that opens successfully is not necessarily sufficient to recreate an invoice or project review.

4. Small entry interactions deserve a trial

On September 11, a Track user described missing description suggestions and extra keyboard steps to select a project in 2.0. They appreciated some new views but preferred Track's entry workflow. This is an individual report, not a verified statement about every current app version. It is a useful reminder to test repeated actions, including how you correct yesterday's entry. Read the entry-workflow feedback.

Run your trial on an ordinary working day. A polished dashboard cannot compensate for an entry workflow your team avoids. Include the person who reviews reports as well as the people starting timers.

What TrackTimer imports from Toggl Track

The current importer helps establish a workspace for future work. It reads from Toggl Track without changing or deleting source data. It is not a Toggl 2.0 importer and does not create an ongoing synchronization connection.

ItemCurrent behavior
ClientsPreview and match an existing client, create one, or skip it.
Active projectsPreview and match, create, or skip; projects without a client can use Internal.
People and project accessReview email matches and proposed access before adding selected access or sending invitations.
Historical time entriesNot imported. Keep an accessible source record or export.
Tasks, tags, rates, budgets, invoices, archived projectsNot imported. Review what you need separately before switching.

You must be a TrackTimer workspace owner or admin and have administrator access to the source Toggl Track workspace. The importer handles one source workspace at a time and checks size limits before applying the preview. The full Toggl migration documentation describes eligibility, limits, matching, and invitation behavior.

A practical migration checklist

Step 1: Decide whether a fresh start is acceptable

Choose a proposed cutover date and decide where older records will remain. If your team needs a single report spanning years of historical and future entries, stop here: TrackTimer's setup importer will not provide that report.

Staying on Track may be the better choice when its existing history and workflow already meet your needs. Use the TrackTimer versus Toggl Track comparison to evaluate the product differences before moving any setup.

Step 2: Preserve the records you will need

Review your completed time reports, invoices, and workspace information before changing subscriptions or access. Open the exports and confirm that the period and people you intended to include are present. Retain source access until you have verified your archive and any contractual recordkeeping needs.

Export availability depends on the product, plan, and permissions. Toggl's Track documentation describes Detailed report exports and workspace JSON exports; do not assume instructions or formats for 2.0 apply to Track. An exported file is an archive, not a promise that TrackTimer can ingest it. Check Toggl Track's export documentation.

Step 3: Preview clients and projects

Use your Toggl Track API token to load the source workspace in TrackTimer's importer. Review the preview before applying it. Match existing records deliberately so that a trial project and its imported equivalent do not become two competing destinations for new time.

Check active projects, their client associations, and anything assigned to Internal. The importer does not carry over rates or budgets, so configure and verify the settings you need for future work separately. Follow the step-by-step importer guide for the exact controls and token handling.

Step 4: Review access before inviting people

Importing clients and projects does not itself send invitations. Review the proposed members and project access, then use the separate action to add selected access and send invitations when ready.

Check email matches and roles rather than assuming source permissions carry over unchanged. New people default to contractor, and administrator privileges are not automatically transferred. Public projects in the source can also produce broader proposed assignments than you expect; inspect them in the preview.

Step 5: Reconcile a sample before cutting over

Track a small amount of clearly labeled trial work. Confirm the person, client, project, date, duration, and any rate settings you will rely on. Agree which system contains the authoritative record during the trial so the same work is not counted twice.

For example, if a project has six hours recorded in Track before the cutover and two hours in TrackTimer afterward, its combined total is eight hours. TrackTimer will contain the two new hours, not the six historical hours. If you also copied the two trial hours into Track, exclude that duplicate when reconciling. This is an illustrative example, not an automated cross-system report.

Check duration and billing separately: eight recorded hours do not establish the charge without the relevant billable status and agreed rate. Our billable-hours guide walks through that calculation.

Step 6: Give the team one clear start date

Once the trial meets your requirements, tell the team where new time belongs, how to find historical records, and who handles corrections to the old period. Update any integrations and shortcuts you intend to use. Review the first reporting period before changing access to the source workspace.

Keep the ongoing routine small: consistent project names, useful descriptions, and a weekly review of missing or ambiguous entries. The agency time tracking workflow provides a starting checklist.

Sources and further reading