Platform Switching
Part of Switching project management platforms
Running a migration pilot on a completed project
Choose a representative completed project, compare source and destination records, and decide whether the transfer route is ready for active work.
Use a completed project to find what a transfer changes before active work depends on it. Choose a project with varied records, save a source snapshot, import it into a labelled test area and compare the result with the snapshot. An importer saying “completed” does not establish that the history is usable.
Choose a revealing project
Choose a project with ordinary tasks and awkward cases: a subtask, a decision explained in comments, an attachment, a closed or cancelled item, a former assignee and a relationship between tasks. Arrange appropriate access to its content in the test area.
Record what the sample cannot represent. If it lacks large files or complex dependencies, check those separately with suitable records.
The pilot cannot establish how people will handle live assignments and handovers after cutover.
Capture a comparison snapshot
Record source project and task identifiers, counts by state, owners, key dates, decision-bearing comments, attachments and task relationships. Note the snapshot time and time zone so later source edits can be identified.
Selected record / Question after transfer
- Task with several comments
- Is the decision readable with enough context?
- Task with an attachment
- Can the intended reader open the file?
- Closed task or archived card
- Did it transfer, and does it remain finished?
- Task with a former owner
- Is the ownership history represented accurately?
- Related tasks
- Is the relationship present, missing or changed?
Key Transfer Checks: Source vs Destination
- Task with several comments
- Is the decision readable with enough context?
- Task with an attachment
- Can the intended reader open the file?
- Closed task or archived card
- Did it transfer, and does it remain finished?
- Task with a former owner
- Is the ownership history represented accurately?
- Related tasks
- Is the relationship present, missing or changed?
Import once and inspect the result
Record the source, destination, route, settings, user mapping and person running the import. Consult the route's current documentation for supported fields and options; do not assume an import status confirms that records transferred as intended. Select records that expose the exclusions relevant to the chosen route.
Compare destination records with the snapshot using an ordinary reader account where possible. Record missing data, changed meaning, access problems and proposed repairs before editing the imported sample. Keep the trial isolated so a repeat import does not create competing live tasks.
Migration Pilot Process
- Record import detailsSource, destination, route, settings, user mapping, and person running the import.
- Consult current documentationVerify supported fields and options; do not assume import status confirms successful transfer.
- Compare using an ordinary reader accountCheck for missing data, changed meaning, access issues, and record proposed repairs.
- Keep trial isolatedPrevent repeat imports from creating competing live tasks.
Decide what the pilot shows
Classify findings as acceptable with an agreed archive, repairable before active migration, or blocking. Give each repair an owner and repeat the affected check after a mapping or route change. Record the evidence behind a decision to proceed or pause.
A live move still needs a fresh snapshot, a cutover point and reconciliation of changes made during the transfer.
Benefits and Limitations of a Migration Pilot
- ProsIdentifies data loss, format mismatches, and access issues before active migration; ensures historical integrity of tasks, comments, and attachments.
- ConsCannot simulate real-time handovers or user behaviour post-cutover; may miss edge cases like large files or complex dependencies unless tested separately.
