Migration Checklist: Moving to Trello

Phase 0

Decide & Plan

Lock the decisions that cause mid-migration scope creep when skipped.

• Document the migration scope by Trello object class: Workspaces, Boards, Lists, Cards, Checklists, Checklist items, Labels, Custom Fields, Power-Ups, Butler automations, Attachments, Members. Each class has a different import path; list which classes are in scope and which are explicitly out.

  Risk if skipped: Discovering mid-cutover that Butler automations were assumed in-scope but were never planned for blocks workflow continuity on day one.

• Decide between a Workspaces model and a Personal Boards model in the destination. Workspaces are the container for team collaboration, board collections, and admin controls. Personal Boards sit outside any Workspace and have different visibility and admin behavior.

  Risk if skipped: Loading boards into Personal scope when the team needed Workspace collaboration forces a board-by-board move after cutover.

• Decide the historical-data scope: how many years of completed cards, how far back for card activity, and whether archived boards are in scope. Trello's Free plan caps Activity History at 250 events per board; older actions roll off the visible log even though they remain in JSON export.

  Risk if skipped: Users expect to see closed work and historical comments on day one and find truncated activity, eroding trust in the new system.

• Decide and document the strategy for record ownership: keep original assignees as members, reassign to a single migration user, or best-match by email. Card members are matched by Atlassian Account email; users not yet provisioned in the destination Workspace cannot be assigned at import time.
• Choose the Trello plan tier before any build work: Free, Standard, Premium, or Enterprise. Tier gates the per-board Power-Up count (Free: 1; Standard and above: unlimited), Butler operation quotas (Free: 250/month, Standard: 1,000, Premium: 6,000, Enterprise: unlimited), unlimited Activity History, attachment size (Free: 10 MB; paid: 250 MB; Enterprise: larger), and admin controls.

  Risk if skipped: Building on Free and discovering a paid-only feature mid-migration forces an unplanned tier upgrade or a re-architecture.

• Decide whether Atlassian Cloud data residency is required and confirm the destination region. Atlassian Cloud offers data residency in regions including US, EU (including Germany), UK, Canada, Australia, Switzerland, India, Japan, Singapore, and South Korea; confirm the destination Workspace is provisioned in the required region.

  Risk if skipped: If residency is required but not provisioned at sign-up, switching regions later requires re-migrating the Workspace through Atlassian's data migration flow.

• Identify GDPR, SOC 2, HIPAA, and sector-specific obligations that apply to the data set. Atlassian publishes a list of subprocessors and offers a pre-signed Data Processing Agreement; confirm the DPA is on file and covers the source data set before loading.

  Risk if skipped: A regulated data set landing in an unconfigured Workspace can trigger a reportable incident before users even log in.

• Set the cutover date, the source-system freeze window, and the read-only date. Pick a low-activity window; communicate it in writing to all source-system users at least two weeks ahead.
• Assign a single accountable DRI for the migration project. One named owner for end-to-end execution; secondaries for export, transform, load, and validation.
• Document explicit success criteria for declaring the migration complete. Examples: zero variance in open card counts per board, every checklist linked to its parent card, every attachment downloadable from the destination, three power users sign off per Workspace.

  Risk if skipped: Without written criteria, the project never formally ends and the source system never gets decommissioned.

• List out-of-scope items explicitly in the project plan. Common out-of-scope items: archived boards older than X years, deleted cards, third-party Power-Up data that lives outside Trello, board background images and stickers.

Phase 1

Pre-Migration Prep

Everything that must be true before the first byte leaves the source.

Phase 2

Source Export

Get every byte you'll need out of the source, in a form you can transform.

• Export every in-scope source object as CSV/XLSX with all standard and custom fields. One file per object class; preserve source IDs as columns for later upsert matching.

  Risk if skipped: Skipping one object class is the most common reason validation fails reconciliation in Phase 6.

• Export the user list with email, role, and reporting structure where available. Email is the match key on the Trello side; capture it exactly as stored in the source.
• Export the list / column / status definitions for each source project. These become the destination's list ordering and label palette; capture both the value and its position.
• Export comments / activity / discussion threads as a separate file. Most source platforms put comments in a different schema than tasks; capture timestamp, author email, and parent card ID.
• Export checklist data with parent card ID, checklist title, item order, and item completion state. Trello supports cards → checklists → checklist items; the import must reconstruct that three-level hierarchy.

  Risk if skipped: Losing item order or completion state forces a per-checklist manual rebuild after import.

• Export attachments — both the metadata mapping and the binary files themselves. Metadata: source card ID, source attachment ID, file name, MIME type, uploaded-by email. Binaries: download to a staging bucket organized by source card ID.
• Export source automation definitions (rules, triggers, scheduled actions) as configuration documents. These do not transfer; capture them as a build-list to rebuild in Butler during Phase 7.
• Screenshot every source dashboard, saved view, and report. Dashboards and reports never migrate as data; the screenshots are the rebuild specification.
• Export label palettes per board with name and color. Labels are board-scoped on Trello; the per-board palette becomes the per-board label configuration.
• Capture an exact UTC timestamp for each export. You'll need this to compute the delta between Phase 2 baseline and Phase 5 final export.

  Risk if skipped: Without an export timestamp, the cutover delta is unknown and last-minute edits silently get lost.

• Run an integrity check on every CSV / XLSX export. Row counts match source UI counts; no truncated cells; UTF-8 encoded; no missing columns.

  Risk if skipped: A silently truncated export propagates downstream; the data is missing in the destination and only surfaces at user-acceptance test.

• Store all exports and binaries in a single staging location with restricted access. Encrypt at rest; restrict to the migration team; tag with the export timestamp.

Phase 3

Transform & Map

The data-engineering core: source files in, destination-shaped files out.

Phase 4

Sandbox Test Migration

Catch every problem in a test Workspace before it costs you in production.

• Load a representative 1–5% sample of cards into the sandbox Workspace using the chosen import method (CSV via Power-Up, or JSON import). Pick samples that span boards, custom fields, attachments, checklists, and comments — not just the easiest cards.

  Risk if skipped: A sample that skips edge cases passes sandbox and then fails at production volume.

• Validate field-by-field on 10 random sandbox cards against the source. Title, description, members, labels, custom field values, checklist items, comments, attachments, due date, position in list.

  Risk if skipped: Skipping field-by-field validation lets one silent mismatch (e.g., dropdown case mismatch) reach production unchallenged.

• Test long strings, special characters, NULL handling, and Unicode in card titles, descriptions, and custom fields. Emoji, RTL scripts, double quotes inside descriptions, embedded newlines.

  Risk if skipped: Unicode and special-character failures only surface at the specific records that contain them; you find them in Phase 6 if you don't test them here.

• Test the import of historical cards (archived / completed) and confirm the audit-trail strategy from Phase 3c actually works. Verify the "Source Created On" custom field is populated and the archive Butler rule (if used) fires.
• Test attachment import: direct upload and external link both. Verify the binary downloads, the MIME type is right, the file name is preserved, and the attachment appears on the right card.

  Risk if skipped: Attachment failures often only surface when a user clicks the file; sandbox is the cheap moment to catch them.

• Test relationship import: checklists → checklist items, card → labels, card → members, card → custom field values. Every cross-object link is a place where the load order can drop data; verify each.
• Run a full-volume rehearsal on a single representative board to surface throughput issues. Size the load to fit within the destination's throughput envelope with backoff on HTTP 429.

  Risk if skipped: Hitting throughput ceilings at production volume stretches the cutover window unpredictably; the rehearsal proves the timing assumption.

• Time every test run and extrapolate to full production volume. If a 1% sample takes 8 minutes, the full load takes ~13 hours; confirm the cutover window covers it with buffer.

  Risk if skipped: Extrapolation reveals whether the cutover window is realistic; learning the answer at 2 a.m. on cutover night is too late.

• Run a Butler rule rebuild test in the sandbox: rebuild three representative source automations as Butler rules / scheduled commands / buttons. Confirm the destination tier's Butler operation quota covers the planned rule load before committing to a tier.

  Risk if skipped: Discovering that a planned automation exceeds Butler's quota tier mid-rebuild forces a tier upgrade or a feature cut at the worst moment.

• Have a domain expert from the using-team spot-check the sandbox cards for correctness. An engineer cannot tell whether a project manager's data is right; only the project manager can.
• Get written sandbox sign-off before proceeding to Phase 5. Email, ticket, or signed memo — a verbal okay does not count.

  Risk if skipped: Proceeding without written sign-off leaves accountability ambiguous when something breaks in production.

Phase 5

Production Cutover

The tightly-sequenced execution window. Densest cluster of risk.

• Confirm source-system freeze; verify no writes in the last hour. Check source audit log or activity history; if any writes happened in the freeze window, address before proceeding.
• Take a final full export of the source data (the delta from Phase 2 baseline). Run the exact same export jobs as Phase 2; this captures last-minute edits.

  Risk if skipped: Skipping the delta export means every edit between baseline and cutover is silently lost.

• Confirm every Butler rule, scheduled command, board button, and card button on destination boards is still disabled. Re-verify; a rule reactivated by accident between Phase 4 and now will fire on the bulk load.

  Risk if skipped: An active rule on cutover night blasts every Workspace member with notifications and burns the entire monthly Butler quota.

• Confirm Power-Up outbound notifications remain paused and integration credentials are still scoped to the migration service account. Live outbound notifications during a 10,000-card load propagate the migration noise into Slack, email, and downstream systems.
• Load members first, then boards, then lists, then cards in dependency order. Members must exist before they can be added to cards; lists must exist before cards can land in them.

  Risk if skipped: Loading cards before lists exist drops position data and forces a per-card move pass.

• Load checklists and checklist items keyed off the parent card source ID. Checklists are board-scoped objects nested under cards; load after the parent card exists.
• Load custom field values keyed off the source card ID and the destination Custom Field definition ID. Verify the Custom Fields Power-Up is enabled on every target board first.
• Load comments / activity keyed off the parent card source ID. Comments are flat per card; preserve order by loading in source-creation-timestamp ascending order.
• Load attachments (binaries first, then card-attachment links). Capture the returned attachment ID and store in the staging metadata.

  Risk if skipped: Attachment uploads are the slowest step and the most throughput-sensitive; running them last means a failure does not strand the rest of the load.

• Use idempotent upserts keyed off the External ID custom field on every load step where supported. Idempotency lets a re-run after a transient failure resume safely instead of duplicating cards.

  Risk if skipped: Without idempotent keys, a partial-failure re-run creates duplicates that have to be cleaned up by hand.

• Capture every job ID, row count, and error log for every load step. Store in a load journal with timestamps; this becomes the source of truth for Phase 6 reconciliation.
• Cross-check destination row counts against source row counts at each step. Members, boards, lists, cards, checklists, checklist items, custom field values, comments, attachments.

  Risk if skipped: Catching a row-count mismatch step-by-step is cheap; catching it at the end means re-running everything to find the missing step.

• If a load step fails partway, stop, diagnose, fix the transform, and re-run idempotently. Do not push through with partial data; partial loads are harder to repair than a clean re-run.
• Re-enable Butler rules, Power-Up outbound notifications, and integration credentials only after every load step completes. Confirm a clean reconciliation in Phase 6 before re-enabling rules that could mutate the loaded data.

Phase 6

Validate

Prove the migration was correct. Do not open the destination to users until this phase passes.

Phase 7

Post-Migration Cleanup

Wrap up so the team can move on and the source can be decommissioned.

• Communicate go-live to all end users with login URL, training links, and a where-to-get-help contact. One announcement per Workspace; include the Atlassian Account sign-in URL and the help contact.
• Run day-one training sessions for end users segmented by role. Cover Workspaces, Boards, Lists, Cards, Labels, Custom Fields, Power-Ups, and Butler basics.
• Rebuild every Butler rule, scheduled command, board button, and card button from the Phase 2 source automation export. Butler rules do not migrate as data; each one is rebuilt from the captured configuration document. Confirm cumulative operations fit within the destination tier's monthly quota.

  Risk if skipped: Forgetting one source automation breaks the workflow it enforced and the team finds out by missing a deadline.

• Rebuild dashboards and reports in the destination (Workspace table view, Workspace calendar view, Dashcards Power-Up, or external BI tools). Trello does not import dashboards as data; reports are rebuilt from the screenshots captured in Phase 2.
• Re-establish integrations: Atlassian Guard SSO, calendar sync, Slack, GitHub, Jira, BI / reporting connectors. Use the platform's standard integration flows and rotate any personal access credentials that were used for the migration run.

  Risk if skipped: Long-lived credentials left active after migration are a soft target for an audit finding against a freshly-loaded Workspace.

• Run a one-hour training refresher 7 days after go-live to address surfaced questions. By day 7, users have hit real workflow questions the day-one training did not cover.
• Set the source system to read-only on the announced read-only date. Confirm no edit paths remain (UI, integrations).
• Archive source-system exports (CSV, JSON, attachment binaries) to long-term storage with restricted access. Retain per the data-retention policy decided in Phase 0; encrypt at rest.

  Risk if skipped: Source archives kept on the team drive without encryption are a soft target for an audit finding.

• Schedule a 30-day post-migration retrospective. Cover what went well, what surprised, what carried forward as known issues.
• Decide and document the source-system decommission date. Typically 60–90 days after read-only, after the final retention window passes.
• Close the migration project formally: final status report, lessons-learned log, sign-off recorded. Project closure ends the engagement and frees the team to move on.