Team Tool Migration Checklist: Data, Integrations, Links, and Cutover

Moving a team to another project tool means moving both its records and the routes through which work arrives. A successful import does not establish that attachments are preserved, support requests reach the right queue, or a client can still open a shared link. Budget for those checks before comparing the old and new subscription bills.

This guide is a planning method, not a report of a migration we performed. Product documentation was checked on September 21, 2026. An earlier version presented an unsupported team migration, timings, integration counts, and costs as personal experience; those claims have been removed. The cost example below is explicitly hypothetical.

Conceptual illustration of migration dependencies, not a diagram of a measured team migration.

What an export or importer actually promises

Start with the source tool’s export documentation and the destination’s importer documentation. They describe different halves of the move. A field present in a download may have no equivalent at the destination; an attachment URL is not necessarily a saved file.

Official documentation checked	Documented limit or behavior	Check to add to your migration plan
Linear importing guidance	Imports require a workspace admin. Source concepts without a suitable equivalent may not import. Dedicated importers generally retain more information than the CLI importer.	Pick the source-specific importer and list unsupported fields before approving the move.
Linear exporting data	CSV exports omit attachment files; descriptions may contain attachment links. Issue-view exports have role-based limits: 250 issues for members, 2,000 for admins or Enterprise owners.	Distinguish a filtered view from a workspace export; retrieve required attachments separately and reconcile the intended scope.
Notion exporting content	Workspace exports exclude pages the exporter cannot access. Reuploading exported content does not instantly recreate the workspace.	Have owners account for private material and test the destination’s reconstruction of representative pages.

These are documentation findings, not hands-on compatibility results. They establish why a file-count check alone is insufficient. For product-fit questions before committing to a destination, the Linear evaluation guide provides separate intake and retrieval exercises.

Build an inventory with a named owner for each dependency

Make a worksheet with these columns: dependency, current location, owner, destination, test, result, and unresolved issue. A row without an owner is unfinished planning. Someone needs to be responsible for confirming that the replacement works, rather than assuming another department checked it.

Search shared documentation, templates, repositories, bookmarks, and automation settings for the old service’s domain and workspace URL. This can expose embedded links and configuration references. It cannot reveal every dependency: an integration may store an account identifier instead of a URL, and a private bookmark may be invisible to the administrator. Supplement the search with the old tool’s integration list and a short walkthrough with each team role.

Dependency to inventory	Example test before cutover	Evidence to keep
Incoming requests	Submit a test request through the actual support or intake route.	Destination record, timestamp, assigned owner.
Outgoing notifications	Change a test record and check the expected notification destination.	Matching record identifier and notification.
Attachments	Download and open representative files using the intended archive or destination access.	File inventory and missing-file list.
Client access	Use a designated external test account to open only the intended material.	Allowed and denied access results.
Recurring work	Trigger or safely simulate a scheduled task in the replacement workflow.	New task, due date, and responsible person.
Historical links	Follow an old reference from a frequently used document.	Working destination or documented lookup route.

This worksheet is a suggested method, not a vendor feature list. Tailor it to the work the team actually does. A failed notification and a failed permission boundary are different problems; recording only a single “migration passed” checkbox hides that difference.

Rehearse with representative records

Choose a small set that exercises the difficult parts of your workflow: an open task with a file, a completed task with a decision in comments, a parent with subtasks, a restricted record, and something assigned to a former colleague. This is a functional sample, not a statistically representative audit. Its purpose is to expose mapping problems before moving the full set.

Decide which material belongs in the live destination and which belongs in a searchable archive. Do not delete old records simply because they look inactive during migration planning. Preserve the source export and a list of exclusions so the decision can be revisited.

Write a field mapping before the rehearsal. “Done” in one system might map to more than one terminal state in another; a deleted user might need an explicitly unassigned owner. Record those decisions instead of letting an importer default silently become policy.

After importing, reconcile totals within the chosen scope, then inspect the sample records. Check descriptions, comments, relationships, dates, files, and permissions independently. A matching issue count does not prove that an attachment opens or that confidential material stayed restricted. Export support is useful evidence, but the acceptance decision belongs to your own test results.

If a critical field fails, keep the destination as a test environment while deciding whether to change the mapping, use another import route, or retain that information in an archive. Do not repeatedly rerun an importer on the assumption that it will repair everything: Linear’s guidance says repeat imports from the same source into the same team skip already imported issues unless the initial import is removed. Check source-specific behavior before retrying.

Treat old links as a separate workstream

Keep a mapping of old record IDs and URLs to new records or archive locations. Prioritize links in active procedures, support material, current projects, and client handoffs. Older references can use a searchable index if rewriting every historical document is impractical.

A paid legacy account is not automatically a redirect service. Continued access depends on the vendor’s plan and permissions, and it does not make old URLs forward to another platform. Test any advertised forwarding feature; otherwise explain how a reader can find the replacement record.

Similarly, do not assume cancellation preserves the archive indefinitely. The data-retention comparison shows why account access and stored data need separate checks. Confirm the particular source tool’s policy before choosing a shutdown date.

Set a cutover gate and a recovery procedure

Choose one system for new work after an announced time. If the old tool supports an appropriate read-only mode, verify it with both ordinary members and integrations. If it does not, document another enforceable way to stop new intake. An email asking everyone to remember a new URL is not evidence that an automated request route has changed.

Approve cutover only when the required records have been reconciled, critical intake tests pass, access tests pass, and someone owns each remaining exception. Record the last successful export and the time it represents. Decide how edits made after that export will be captured: a short agreed freeze or a tracked final transfer, depending on what the tools support.

Write the recovery procedure before it is needed. Specify who can call a rollback, which failures justify it, and where work created after cutover will be recorded. Reopening the old tool without reconciling new destination records can leave two conflicting versions of the same task. A recovery plan therefore needs a change log, not just a retained login.

There is no universal number of days for this phase. End parallel access based on acceptance criteria and the team’s workflow, rather than an invented promise that every migration takes a particular number of weeks.

Calculate switching cost separately from subscription savings

Here is a hypothetical eleven-person team, using invented planning inputs for arithmetic only. These are not vendor prices, measured labor costs, or a forecast of your team’s migration.

Planning input	Assumption	Calculated cost
Administrator preparation and validation	12 hours at an internal planning rate of $40/hour	$480
Team orientation	11 people × 1 hour × $40/hour	$440
Legacy subscription overlap	2 extra months at $90/month	$180
Total incremental switching cost	$480 + $440 + $180	$1,100

Suppose the old subscription costs $90/month and the replacement costs $60/month at the same usable seat count and billing terms. The ongoing saving is $30/month. Recovering the $1,100 switching cost from that saving alone takes about 36.7 months after the old subscription ends: $1,100 ÷ $30. The $180 overlap line counts the extra old subscription while the replacement is already in use; do not add those same months again elsewhere.

Labor valued at an internal rate is an opportunity-cost estimate, not necessarily a new cash payment. Separate the cash budget from staff time when deciding whether the move is affordable. Add any known termination charge, required paid importer, or extra training to your own worksheet. Productivity benefits may justify the move sooner, but write down how you will measure them instead of inventing a dollar saving.

At the next quarterly stack audit, compare the actual invoice, retained legacy access, and unresolved migration work with the plan. The useful outcome is a functioning replacement with an explainable cost. An import-complete banner is only one piece of that evidence.