Phase 0

Decide & Plan

Resolve the scope, owner, residency and success-criteria questions before any export or build work begins.

Document the migration objective and the trigger event in one paragraph. Capture why the move is happening now (tool consolidation, plan change, residency, M&A, sunset of source system) so later scope debates can be settled against the original intent.
Define the in-scope object set: Workspaces, Folders, Boards, Groups, Items, Subitems, Updates, Files, Users, Teams. List each object explicitly with an in-scope or out-of-scope flag. Treat Updates threads, Docs and dashboards as separate decisions from Items.
Risk if skipped: Implicit scope expands mid-project as stakeholders discover missing data, blowing the timeline.
Decide the historical-data window: how many years of source items, comments and attachments come across. Pair each in-scope object with a date cut-off. Older items can be archived to read-only storage instead of imported.
Risk if skipped: Importing unbounded history inflates board item counts, breaches per-board ceilings and slows every view.
Choose the monday.com plan tier before any build work. Map required features to plan: Dependency column, Time Tracking, formula columns and private boards require Pro; advanced provisioning, audit log, HIPAA and IP restrictions require Enterprise.
Risk if skipped: Building on Standard then discovering a Pro-only column type forces a re-architecture mid-migration.
Select the hosting region: US, EU (Frankfurt) or APAC. Region is set at account creation and cannot be changed after the fact by self-service. EU residents subject to GDPR data-residency commitments must request EU before the account is provisioned.
Risk if skipped: An account created in the wrong region requires a full account-to-account move to relocate data later.
Identify legal and compliance constraints that gate the cutover. Capture GDPR data-processing addenda, HIPAA BAA requirement, SOC 2 evidence needs, customer contracts that name the source platform, and any retention policies that change on cutover.
Risk if skipped: A missing signed BAA on an Enterprise HIPAA tier means uploaded PHI is non-compliant from day one.
Assign a single accountable migration owner (DRI) and a named delegate. One person signs off each phase. Cross-functional input is welcome; ownership is not shared.
Document explicit success criteria for cutover. Examples: every active item has the same status, owner and due date in destination as source; every attachment opens; every dashboard has a matching destination view.
Risk if skipped: Without written criteria, sign-off becomes a negotiation instead of a verification step.
Set the target cutover window, the source-system freeze date, and a no-go fallback date. Pick a window that avoids fiscal close, sprint boundaries and known release freezes for downstream teams.
List explicit out-of-scope items in writing. Common exclusions: source-system automations, dashboards, archived items beyond cut-off, source-system custom apps. Saying "no" up front is cheaper than saying it later.

Phase 1

Pre-Migration Prep

Cleanse the source, build the destination workspace shape, and stage users so the import has somewhere correct to land.

1a. Source-system audit and cleansing

Export source record counts per object as a numeric baseline. Capture counts per project, per status, per owner. Save the export as the reconciliation reference for Phase 6.
Risk if skipped: Without a baseline, post-cutover deltas can be explained away as "normal" instead of investigated.
Run dedup analysis on source items using a stable match key. Match on source ID where present, otherwise on (project, title, owner, due-date). Resolve duplicates in the source while you still have its dedup tooling.
Risk if skipped: Duplicates merged after import require manual cleanup against destination IDs that did not exist at source time.
Normalize email casing and verify each user email resolves to a real mailbox. Lowercase all email addresses before export. Items assigned to bounced mailboxes need owner reassignment before cutover.
Standardize date and datetime values to ISO-8601 with explicit timezone. monday.com stores date columns in UTC and renders per-user timezone; mixed-format source dates surface as off-by-one-day errors in calendar and timeline views.
Risk if skipped: Date column imports silently shift days at the date-line, producing wrong deadlines on hundreds of items.
Identify and resolve items missing required fields in the destination schema. Required columns in monday.com block item creation if empty. Pre-fill or strip the requirement before load.
Risk if skipped: Import jobs abort partway when a required column is unset, leaving the board in a half-loaded state.
Audit source picklist / status values and rationalize them. Status columns on monday.com cap at 40 labels per column. Collapse near-duplicate statuses ("Done", "Done!", "Completed") in source before mapping.
Risk if skipped: Hitting the 40-label cap mid-import forces emergency label consolidation under cutover pressure.
Audit source dropdown / multi-select fields against the per-board 20,000-label ceiling. monday.com supports 1,000 labels per Dropdown column and 20,000 labels per board across all dropdowns. Aggressive tagging in source can exceed this.
Document and resolve any field-level encoding issues (non-UTF-8 text, smart-quote artefacts). Re-encode to UTF-8 at export. The CSV importer rejects mixed encodings silently in some cells.

1b. Destination workspace and schema setup

Provision the production monday.com account in the chosen region. If EU residency is required, request the EU region during provisioning. Self-service account creation defaults to US.
Risk if skipped: An EU-resident customer left on the US tenant must be moved account-to-account later, costing a second migration.
Provision a separate sandbox account or sandbox workspace for the dry run. monday.com does not offer a built-in sandbox; create a separate paid account on the same tier or use an isolated workspace with no production users.
Risk if skipped: Testing in the production workspace exposes incomplete data to end users before sign-off.
Configure account-level settings: default timezone, workweek, language, default item-name column. These cascade into board defaults and affect how imported dates render.
Design and create the Workspace → Folder → Board → Group hierarchy in production. Decide whether each source project becomes a Board (one project per board) or a Group inside a portfolio Board. Document the rule and stick to it.
Risk if skipped: Mixing the two models on the same migration breaks rollups, Mirror columns and cross-board reporting.
Create every column on every destination board before any import. Decide column types up front: Status (40-label cap), Dropdown (1,000-label cap), Date, Timeline, People, Numbers, Text, Long Text, Dependency, Time Tracking, Mirror, Connect Boards.
Risk if skipped: Importing into a missing column silently drops the column's data on the existing-board flow.
Stay under the 100-column file limit and the existing-board 50-imported-column cap when designing board width. Native CSV/Excel import accepts up to 100 columns in the file with the first 50 imported on a new board, 100 on existing. Split very wide source schemas into separate boards or mirror groups.
Risk if skipped: A 70-column board imported into a fresh board loses everything beyond column 50 with no per-cell warning.
Stay under the 10,000-item-per-board ceiling (100,000 on Enterprise) when sizing the board layout. If a source project exceeds the ceiling, split by year, region or sub-project across multiple boards joined by Connect Boards.
Risk if skipped: Loads above the ceiling fail mid-import and partial data is non-trivial to roll back.
Configure the Dependency column mode (Flexible, Strict or Blocking) on every board that needs dependencies. Mode is per-column and applies to all dependency relationships on that board. Pick the mode before loading any dependency data.
Risk if skipped: Switching dependency mode after load can re-shift hundreds of dependent dates.
Add the Time Tracking column to boards that need session history. Time Tracking is a Pro+ column and stores sessions with start, stop, user and duration. Add it before importing any historical time entries.
Build Connect Boards and Mirror column relationships up front to match source cross-project links. Connect Boards links one item to items on another board; Mirror reflects a column from the linked item. Both must be configured before the upsert that creates the relationship.
Risk if skipped: Items load without their cross-board links and have to be re-stitched item-by-item after cutover.
Set column-level permissions for any sensitive fields (budget, salary, client revenue). Column permissions are configured per board; without them, every board member can read every column.
Create Teams and assign users to Teams matching the source-system access groups. Teams are the unit monday.com uses for board sharing on private and shareable boards.
Provision all destination users with the correct role: Admin, Member, Viewer or Guest. Guest seats are billed differently from Member seats. Pick the role intentionally; do not default everyone to Member.
Risk if skipped: Over-provisioning Member seats inflates the seat count and the annual invoice.
Configure SSO and (Enterprise) automated provisioning before user load. Automated user provisioning is Enterprise-only. JIT-via-SSO works on lower tiers but does not deprovision.
Disable, pause or scope every Automation recipe on destination boards until cutover. Recipes firing on imported items will notify, reassign or move thousands of items before validation.
Risk if skipped: Status-change recipes fire on every imported row, generating a flood of emails and Slack pings to end users.
Disable destination email notifications for users involved in the import. Bulk item creation generates a notification per item per subscriber by default.
Provision a dedicated import service account separate from any personal admin. Use a dedicated account, not a personal admin, so post-cutover audit logs show migration writes separately from human edits.
Risk if skipped: Mixing migration writes with admin writes makes audit-log triage impossible after cutover.

1c. People and process prep

Announce the source-system freeze window to every affected user. Include the exact start time, the read-only date and the destination-go-live time. Repeat 72h, 24h and 1h before freeze.
Schedule destination training for end users, segmented by role. Item owners, board owners and workspace admins need different sessions. Run them in the week before cutover so the muscle memory is fresh.
Designate first-responders for the 48 hours after cutover. Name two on-call admins per timezone. Publish a single intake channel for issues so triage is centralized.
Pre-write the cutover go/no-go checklist and circulate it to every stakeholder. Items: source frozen, exports complete, sandbox sign-off in hand, destination automations paused, rollback plan ready.

Phase 2

Source Export

Pull every in-scope object out of the source in a transformable format, with timestamps captured so the delta is known at cutover.

Export every in-scope project / board as CSV or XLSX with all standard and custom columns included. Use the source system's bulk export. Save the file timestamp with the file.
Risk if skipped: Per-record extraction loops on large projects rarely finish without interruption and produce inconsistent snapshots.
Export tasks / items separately from projects / boards so the parent-child relationship is preserved. Keep a join key (project_id or board_id) in the item export.
Export subtasks / subitems with an explicit parent_item_id column. monday.com subitems require a parent item. The link must be present in the import file.
Risk if skipped: Subitems without a parent link land at the top level and have to be reparented one by one.
Export task dependencies (predecessor / successor pairs) as a separate relationship file. Capture (from_item_id, to_item_id, dependency_type). monday.com's Dependency column accepts pairs but the import file must enumerate them.
Export time-entry / time-tracking history as a separate file with item_id, user_email, start_ts, end_ts and duration. Time Tracking sessions on monday.com are stored per item with full session-level history; map source time entries to sessions.
Risk if skipped: Aggregated time totals without session detail lose the ability to attribute hours to the right user post-migration.
Export comments / updates / notes as a separate file with item_id, author_email, created_at and body. Comments do not import into the native Updates thread via CSV; capture them anyway for the chosen preservation strategy in Phase 3.
Risk if skipped: Discarding source comments because they "do not import natively" loses years of decision context.
Export the user list with email, full name, role and team membership. Map source roles to monday.com Admin / Member / Viewer / Guest before user load.
Export the full source attachment set with filename, size, owner, content-type and parent item_id. Pull binaries to a staging bucket. Capture an MD5/SHA-256 per file so post-import integrity can be verified.
Risk if skipped: Re-fetching missing attachments after the source goes read-only is harder than re-uploading from a fresh pull.
Export workflow / status definitions and their order per source object. These become the Status column label list and order on destination boards. Capture color codes too where reusing palette matters.
Export the source automation / rule definitions as documentation, not data. Recipes do not transfer; screenshots and a JSON dump of each rule become the rebuild spec on monday.com.
Export reports, dashboards and saved views as definition + screenshot pairs. Dashboards rebuild manually on monday.com using widgets. Captured definitions make the rebuild a documentation task, not a discovery task.
Export permissions / sharing per project so destination board permissions can be reconstructed. Capture both the share scope (public, team, named users) and any field-level restrictions.
Capture the exact timestamp of every export. This timestamp defines the delta the cutover-day export must catch up. Write it into the file metadata, not just the filename.
Risk if skipped: Without a known export timestamp, the delta export at cutover misses any record edited inside an ambiguous window.

Phase 3

Transform & Map

Build the field mapping, run the transforms and resolve every PM-specific structural question before sandbox load.

3a. Mapping spreadsheet

Build a master mapping spreadsheet: one row per source field with destination column, type, transform and required-on-import flag. Include nullability, default value and whether the column is part of any Connect Boards or Mirror relationship.
Risk if skipped: Without a single mapping artefact, transformation rules drift between engineers and the same source field maps two different ways.
Resolve every source field with no destination equivalent: drop, concatenate into Long Text, or create a new column. Document the decision in the mapping spreadsheet. Concatenated fields keep history without bloating column count.
Decide the upsert key per object and document it. Typical: source system ID stored in a Text column on monday.com. ingest_items can update items that match this key on re-runs.
Risk if skipped: Without a stable upsert key, partial re-imports duplicate every previously loaded row.
Resolve Status column label mismatches against the 40-label cap per column. Map ("In Review", "Under Review", "Reviewing") to one label; document the consolidation.
Resolve Dropdown column label mismatches against the 1,000-per-column and 20,000-per-board caps. Multi-select source fields with high cardinality (e.g. tags) often need to be collapsed or split across multiple Dropdown columns.
Decide the ownership strategy: best-match by email or assign to a single "migration" service user. monday.com's People column needs a valid user reference. Items assigned to deactivated emails fail.
Risk if skipped: Items whose owner emails do not resolve to any provisioned user fail to load on the People column.
Decide the historical-timestamp strategy. monday.com does not let import overwrite system created_at. Either accept import-time created_at and store the original in a custom Date column, or use ingest_items to preserve where supported.
Risk if skipped: If "original created date" reports drive SLA calculations, losing source timestamps misrepresents historical SLA performance.

3b. Data transformation

Convert date and datetime fields to ISO-8601 with explicit timezone. monday.com Date columns store date-only; Timeline and Date with time store full timestamps. Confirm the column type per field and write the correct shape.
Risk if skipped: Datetime values without timezone shift up to 24 hours depending on the importer's interpretation.
Normalize phone numbers to E.164 (+countrycode...). Use a phone-number normalization library in the transform step.
Convert currency values to the destination's stored decimal precision and separator. Numbers column on monday.com accepts plain numerics; strip currency symbols and thousands separators before write.
Truncate or split text fields that exceed destination column length. Item names truncate at the platform's name length; Long Text columns accept longer content. Re-route any over-length text to Long Text.
Risk if skipped: Truncation without warning silently loses the back half of long titles.
Re-encode any non-UTF-8 text content as UTF-8. Mixed-encoding CSV files surface as garbled cells with no row-level error.
Escape commas, newlines and quote characters in CSV cells per RFC 4180. Newlines inside item names or text columns split rows in some importers; quote-wrap and double-escape internal quotes.
Risk if skipped: An unescaped newline in a single cell can break every subsequent row's column alignment.
Normalize boolean fields to monday.com Status or Checkbox column values. Source booleans (Y/N, 1/0, true/false) all need to map to a single representation on destination.

3c. Relationship and audit-trail decisions

Implement the chosen ownership strategy across the transformed files. Either resolve every source owner email to a monday.com user_id, or hard-write the migration service user_id everywhere.
Stamp original source IDs into a dedicated Text column on every item. Names like source_system_id make later cross-system reporting and audit-log tracing possible.
Risk if skipped: Without a back-reference, debugging "why did this item end up here" requires a manual hunt through the source export.
Stamp original created_at / modified_at into dedicated Date columns alongside the new system timestamps. These power the audit-trail validation in Phase 6.
Decide the attachment strategy: re-upload binaries to monday.com vs. link out to external storage (Google Drive, OneDrive, Dropbox, Box). Per-file upload limit on the Files column is 500 MB; account storage is plan-capped. Large or numerous binaries are better preserved as cloud links.
Risk if skipped: Re-uploading every binary can exhaust the account storage cap and silently fail later uploads.

3d. monday.com structural transforms

Map source project hierarchy onto the Workspace → Folder → Board → Group → Item → Subitem structure. Decide where each level of the source nesting lands. A common pattern: source portfolio → Workspace; source program → Folder; source project → Board; source phase → Group; source task → Item; source subtask → Subitem.
Risk if skipped: Flattening five source levels onto monday.com's six without an explicit mapping produces unpredictable parent-child links.
Translate source task dependencies into Dependency column pairs and align them with the chosen Dependency mode. Flexible mode allows manual override; Strict and Blocking modes enforce the timeline. The mode must already exist on the destination board (per Phase 1) before pairs are written.
Risk if skipped: Importing dependency pairs into a Strict-mode column shifts hundreds of due dates the moment the first pair is created.
Translate source time entries into Time Tracking column sessions on a per-item basis. Each session needs start, stop, user and duration. The Time Tracking column stores session-level history that is editable post-load.
Build Connect Boards link payloads and Mirror column dependencies for cross-board relationships. Connect Boards holds the link itself; Mirror columns reflect a column from the linked item. Decide which columns Mirror reflects before load so the linked column exists.
Risk if skipped: Mirror columns referencing a not-yet-created source column show as empty cells across the destination board.
Re-create source recurring-task rules as monday.com Automation recipes scheduled on the destination. Recurring items are a recipe-driven feature on monday.com ("Every time period, create a new group / item"). Document each source recurrence and queue the recipe for activation post-cutover.
Plan how source Updates / comments will be preserved on destination. The Updates thread cannot be backfilled by CSV. Options: re-post each comment as a new Update after item creation, or concatenate into a Long Text "history" column on the item.
Risk if skipped: Re-posting every historical update at high rate against the destination platform's per-tenant throughput caps will stall partway through.
Decide whether attachments land on the Files column or remain as cloud-storage links on a Link column. File column uploads count against account storage and re-host the binary; Link columns to Google Drive / OneDrive / Dropbox / Box preserve the source-of-truth elsewhere.

3e. Throughput planning

Choose the import mechanism per object type: native CSV/Excel UI, ingest_items, or backfill_items. Native UI suits one-off boards under 8,000 rows. ingest_items handles recurring programmatic loads at 10,000 rows per job. backfill_items handles 20,000 rows per job and is account-admin-only for an initial seed.
Size jobs to respect the platform's complexity budget. Per-tenant reads and writes are capped on a per-minute complexity budget. Cost out each batch before scheduling.
Risk if skipped: Unsized batches trigger complexity-limit errors mid-job, leaving partial loads that have to be reconciled by hand.
Stage import files in the order: Users → Teams → Workspaces → Folders → Boards → Groups → Items → Subitems → Dependencies → Time entries → Updates → Files. Each later step depends on IDs produced by earlier steps; the order is fixed.
Risk if skipped: Loading subitems before items leaves orphans; loading dependencies before items errors at every pair.

Phase 4

Sandbox Test Migration

Run the full pipeline end-to-end into the sandbox, catch every gotcha, and sign off before production cutover.

Load a representative 1–5% sample of each object into the sandbox. Sample across status values, owners, dates and custom fields. Random sampling is fine; cherry-picked easy rows are not.
Risk if skipped: Sampling only the easy rows hides the field-type gotchas until production load.
Validate field-by-field on 10–20 random sandbox items that values landed in the right column with the right type. Open each item and compare every column to the source row.
Specifically test long strings, special characters, embedded newlines and emoji. These are the cells that surface CSV escaping bugs.
Test Status column imports against the 40-label cap and confirm new labels are not auto-created beyond the cap. Verify each label landed in the intended position and color.
Test Date and Timeline column imports across timezones to confirm no day-shift. Pick sample rows from at least three timezones, including one east of UTC and one west, and verify the rendered date matches the source.
Risk if skipped: Day-shift bugs found in production force a per-row recompute against the source export.
Test Dependency column loads in the chosen mode. Confirm dependency pairs link the right predecessor and successor, and that no due date shifted unexpectedly under Strict or Blocking mode.
Test Time Tracking column loads with session-level history. Open a sample item's Time Tracking history and confirm session start, stop and user are correct.
Test Subitem imports and confirm parent linkage is preserved. Native Excel import flow imports subitems as items by default; verify the chosen import path actually preserves the subitem relationship.
Risk if skipped: Subitems landing as top-level items requires per-item conversion after the fact.
Test Connect Boards and Mirror column linkage. Open a destination item and confirm the linked item resolves and Mirror cells render the expected source column.
Run a full-volume timing test of the heaviest board. Time the load of the largest single board to confirm the cutover window has headroom.
Risk if skipped: A production board that loads slower than the cutover window leaves the team in a half-migrated state at go-live.
Track cumulative complexity-point consumption across the test runs. Sandbox runs draw against the same per-minute quota. Capture the burn rate per job size so production sizing is empirical.
Have a domain expert from the team that uses the data spot-check 25–50 sandbox items end to end. Engineers catch type bugs. The team that lives in the data catches semantic bugs.
Document every defect, its root cause, and the transform fix. A defect log feeds Phase 6 validation and the post-mortem.
Re-run the sandbox load after every transform fix until a full clean run completes. Do not advance to production with known open defects.
Risk if skipped: Carrying defects forward to production turns the cutover into the discovery phase.
Get written sandbox sign-off from the migration sponsor before scheduling cutover. Sign-off names the sponsor, the date and the explicit success criteria met.

Phase 5

Production Cutover

The tightly-sequenced load window. Freeze, delta-export, load in order, verify counts at each step.

Confirm the source freeze is in effect and that no new writes have occurred in the last hour. Have an admin lock the source to read-only at the documented freeze time.
Risk if skipped: A late source write after the delta export creates an item that never lands on monday.com and is invisible to validation.
Take the cutover-day delta export across every object type. Capture every record changed since the Phase 2 baseline timestamp. Merge into the staged import files.
Re-run the transform pipeline against the merged datasets and produce final destination-shaped import files. Sanity-check the row counts match the merged input.
Confirm destination Automation recipes are paused and notifications are suppressed. Re-verify the Phase 1 pauses are still in effect; recipe state can drift between Phase 1 and cutover.
Risk if skipped: A re-enabled recipe firing on import generates thousands of notifications mid-cutover and floods user inboxes.
Execute loads in dependency order: Users → Teams → Workspaces → Folders → Boards → Groups → Items → Subitems → Dependencies → Time entries → Updates → Files. Use ingest_items for recurring volumes and backfill_items only for the largest seed loads, per the Phase 3 plan.
Risk if skipped: Out-of-order loads error on missing parent IDs and force a partial rollback.
Use idempotent upserts keyed on the source-system-ID column for every item load. ingest_items supports update-on-match; configure the match key to the dedicated source-ID Text column.
Risk if skipped: Non-idempotent inserts on re-run double every previously loaded row.
Capture job_id, row count, success count, error count and error log for every ingest_items / backfill_items job. Poll fetch_job_status until the job completes and persist the result to the migration log.
Cross-check destination item counts against source row counts at the end of every load step. If counts diverge, stop, diagnose and re-run the step before advancing.
Risk if skipped: Continuing past a count mismatch propagates the deficit through every downstream step.
If a load step fails partway, halt the pipeline, diagnose, fix the transform and re-run the failed step idempotently. Do not push through with partial data and plan to clean up later.
Re-enable destination Automation recipes once all loads complete and Phase 6 validation has started. Re-enable in waves: first the read-only recipes (notifications), then the side-effect recipes (status changes, item moves), then the integrations.
Re-enable destination notifications and email preferences. Reverse the Phase 1 silencing so the platform behaves normally for end users.

Phase 6

Validate

Prove the migration was correct on counts, relationships, audit trail and end-user workflows before opening the destination to the org.

6a. Reconciliation

Compare total item count per board: source vs. destination. Investigate any non-zero delta against the migration log; expect the delta to resolve to known excluded rows or known errors.
Risk if skipped: An unexplained count delta means rows are missing or duplicated and the team does not know which.
Compare open task count per project: source vs. destination. An open-status item that lands closed (or vice versa) skews every dashboard the moment users log in.
Compare subitem counts per parent item across the largest 20 parents. Subitem orphan rates surface here.
Compare dependency-pair counts per board across the boards that use Dependency columns. Dependency rows often drop quietly during transform.
Cross-check 25–50 randomly selected items field-by-field between source and destination. Cover every column type at least once across the sample. Document any divergence and decide whether to fix or accept.
Risk if skipped: Skipping random sampling means systematic bugs in rare columns ship to production users.
Verify every custom column has at least one populated value where expected. An entirely empty destination column usually means a mapping bug.

6b. Relationship validation

Verify Subitem-to-Item relationships on a sample of 25 items. Open each item and confirm the subitems list matches source.
Verify Connect Boards links resolve and Mirror columns render correctly. Sample one link per relationship type; confirm both directions resolve.
Risk if skipped: Broken Mirror columns surface as empty cells in dashboards long after cutover.
Verify Time Tracking sessions on a sample of items with the heaviest historical time entries. Open the Time Tracking history and compare per-session entries with the source export.
Verify File column attachments open and the file content matches the source binary. Spot-check 20 random attachments; verify checksums match the Phase 2 capture for at least 5.
Risk if skipped: Truncated or replaced binaries are only discoverable by opening the file.
Verify People column owners resolve to active users on the destination account. Any item still pointing to the migration service user has not had its true owner reassigned.

6c. Audit and compliance validation

Verify the original created_at / modified_at columns are populated on every item. Confirm the original timestamp survived into the dedicated custom Date columns per Phase 3.
Risk if skipped: Items missing the back-reference timestamp lose their audit context permanently.
Confirm the destination account is in the contracted hosting region. Account admin → hosting region; for EU customers, verify the region is Frankfurt and that no replica exists outside the EU.
Risk if skipped: A US-region account holding EU personal data breaches GDPR Article 44 from cutover onward.
Verify the signed BAA is in force if the account holds PHI. HIPAA-Compliant Enterprise Tier must be active and the BAA countersigned before PHI is uploaded.
Pull the destination Enterprise Audit Log and confirm the cutover writes are recorded. Filter on the migration service account user_id; cross-check writes against the migration log.
Document the data-retention policy on the destination workspace. Capture: who can delete, how long deleted items remain in the recycle bin, and the encryption-at-rest position.

6d. User-acceptance check

Have 3–5 power users from each affected team validate their day-to-day workflows. Scripts: create an item, change its status, set a dependency, log time, mention a teammate, open an attachment, run a view.
Risk if skipped: Skipping UAT means real workflow defects ship to every user simultaneously on day 1.
Have a board owner re-create one dashboard end-to-end on destination and compare against the source. Dashboards rebuild manually; a clean dry run before opening the platform avoids day-1 reporting gaps.
Re-test one full recurring-task recipe end-to-end. Recurring item recipes do not migrate; confirm the rebuilt recipe fires correctly on the documented schedule.
Capture and triage every UAT defect; classify each as blocker / non-blocker. Blockers gate the Phase 6 sign-off. Non-blockers carry into Phase 7 cleanup.

6e. Sign-off

Capture written sign-off from the migration sponsor against the Phase 0 success criteria. Sign-off references the success criteria document by name and explicitly states each criterion is met.
Risk if skipped: Without written sign-off, scope debates re-open weeks later under the heading "the migration was never finished".

Phase 7

Post-Migration Cleanup

Open the destination to end users, rebuild what did not transfer, and decommission the source on a scheduled date.

Communicate go-live to every end user with login instructions, training links and the support intake channel. Pin the announcement in the company knowledge base; do not rely on email alone.
Run live training sessions for end users segmented by role. One session for item owners, one for board owners, one for workspace admins. Record each session.
Set the source system to read-only and announce the read-only date. Read-only protects the source as a forensic snapshot during the 30/60/90-day fallback window.
Risk if skipped: An editable source post-cutover invites users to update both systems and split the source-of-truth.
Rebuild dashboards on the destination using monday.com widgets. Use the Phase 2 dashboard-definition captures as the rebuild spec. Tag every widget with the source name for traceability.
Rebuild Automation recipes using the Phase 2 documentation as the spec. Build in waves: notification recipes first, then status-change recipes, then cross-board recipes. Test each recipe in isolation before the next.
Risk if skipped: Rebuilding every recipe at once and then enabling them in bulk surfaces interaction bugs as a single tangled outage.
Rebuild recurring-task recipes ("Every time period, create...") on the destination. Verify the next-fire date is correct; otherwise the first occurrence post-cutover may not match the source cadence.
Re-establish integrations to other systems: calendar, email, BI, identity provider, file storage. Each integration is its own configuration block; do not bundle them into a single "reconnect everything" ticket.
Configure ongoing user provisioning via the Enterprise provisioning flow or SSO JIT. Without provisioning, leavers retain access until manually removed.
Risk if skipped: Leavers retaining access exposes the platform to insider-risk breaches between offboarding and manual removal.
Schedule a 30-day retrospective with the migration team and an executive sponsor. Capture what went well, what did not, and what would change for the next migration.
Decide and document the source system's decommission date. Common pattern: 90 days after cutover, after the final retention window passes. Communicate to every user.
Archive every source export and the migration log to long-term storage. Encrypted cold storage in S3, Azure Blob or equivalent. Tag with the cutover date and the retention period.
Risk if skipped: Discarded source exports remove the only forensic record if a post-cutover dispute arises a year later.
Close the migration project formally: final status report, lessons-learned doc, project closure email. A formal close prevents the project re-opening every time someone finds an edge case post-cutover.

Watch list

Risks to track throughout

These risks live across multiple phases — keep an eye on them from kickoff through cutover.

Platform complexity-budget burn under heavy load

monday.com meters every read and write against a per-tenant complexity-points-per-minute budget. Sandbox dry runs, transform-fix re-runs and the production load all draw against the same budget. Track cumulative complexity consumption from Phase 4 onward so the cutover window does not stall on a complexity-limit error.
Column-type drift across boards

monday.com does not enforce a schema at the platform level: the same field on two boards can be Status on one and Dropdown on another. Once Connect Boards or Mirror columns reference both, the mismatch surfaces as silent empty cells. Lock column types via the master mapping spreadsheet in Phase 3 and audit them as part of every sandbox and production load.
Automation recipes firing on imported items

Recipes on destination boards fire on every item creation and column change unless paused. A 10,000-item load on a board with five recipes can generate 50,000 notification events, status moves and downstream side-effects in minutes. Disable recipes account-wide before any import and re-enable them in waves only after Phase 6 validation has started.
Per-board ceilings and storage caps

Boards cap at 10,000 items on Standard/Pro and 100,000 on Enterprise; account storage caps depend on plan and accumulate as attachments are re-uploaded. Both ceilings are easy to forget during scope sizing and hard to fix once hit. Size boards and decide the attachment strategy (re-upload vs. external links) in Phase 0 and Phase 3 before any binary lands.