Moving from SharePoint, Asana, or monday.com to Confluence and Jira requires three things decided before data moves: where the content lands, who owns the permissions, and how history carries over. Skip any of the three and you get a copy of today's problems on a new platform. This guide covers the planning, execution, and governance work behind a migration that actually holds up.
Atlas Bench runs these migrations as an Atlassian Platinum Solution Partner. We design access before the first page moves, so you land on a platform someone owns rather than the same mess at a new address.
Tool sprawl starts one team at a time. Documentation ends up in SharePoint, plans in Asana, boards in monday.com, and side work in Trello or ClickUp. Each tool has its own accounts, its own groups, and its own sharing rules. Nobody can say in one place who has access to what.
Atlassian consolidates that work into two products: Jira for tracking and Confluence for documentation. Both connect to a single identity provider through Atlassian Guard, so one directory governs who sees what across every space.
The consolidation also sets the foundation for governance. Once people and their access live in one system, you can build change control, audit evidence, and reporting that actually trace back to named owners.
History is not one thing. It includes work item comments and timestamps in Asana or monday.com, document versions in SharePoint, attachment metadata, and the audit trail of who changed what and when.
Each source tool exports a different slice. Atlassian's importers for Asana and monday.com bring tasks, subtasks, comments, and attachments, but formula columns, mirror columns, and certain custom field types do not carry over. SharePoint has no Atlassian importer at all; its content moves by export and import, or through a Marketplace app when the volume requires one.
Decide deliberately what history you need in the new system versus what stays in a read-only archive. A pilot import for one team per tool is the fastest way to confirm what comes across and what does not.
SharePoint uses inheritance-based permissions: site to library to item. Confluence uses an additive model with global permissions, space roles, and page restrictions. The two do not map directly to each other.
Jira permissions are layered similarly: global, space-level, and work-item-level security schemes. If you copy permissions from each old tool's sharing settings, you recreate the sprawl you set out to fix.
The alternative is to design permissions from groups synced from your identity provider. Those groups are edited in one place (Okta, Entra ID, or another directory), and SCIM provisioning keeps them current in Atlassian Cloud automatically.
Atlassian provides direct importers for Asana, monday.com, ClickUp, and Trello. Each one brings a different subset of data. Asana imports tasks, sections, comments, dates, and attachments. Custom fields require a paid Asana plan. The monday.com importer covers items, subitems, files, and dependencies, but drops formula, mirror, and board relation columns.
Trello checklists and custom fields do not import into software spaces. ClickUp rollups, progress fields, and comment replies stay behind, and each import handles up to 10 lists. Azure DevOps has no direct Atlassian importer; that route runs through a CSV export and the Jira CSV import.
SharePoint has no Atlassian importer at all. Confluence imports Word files (including from OneDrive), Google Docs, Notion exports, and zipped HTML. SharePoint .aspx pages need conversion to a supported format before they can enter Confluence. The document import handles up to 30 files and 50 MB per batch.
List every site, document library, list, and page. Identify the owner of each, the last time it was updated, and whether the content belongs in Confluence, in an archive, or nowhere. Most SharePoint estates contain years of content nobody uses, and migrating all of it creates noise on the other side.
Map each SharePoint site to a Confluence space. Flatten deep folder libraries into page trees with labels instead of nested directories. Agree on naming, page templates, and who administers each space before any content moves.
Confluence imports Word files (including from OneDrive), Google Docs, Notion, and zipped HTML. SharePoint .aspx pages need conversion to a supported format first. Every internal SharePoint link must be rewritten to the Confluence page ID after import, using a mapping table built during the migration.
Import one team's content, reconcile page counts and attachments, and check permissions with the content owner. Confirm that restricted content lands in a restricted space. Atlassian's own HTML import guide warns that open default permissions can expose private content.
Asana tasks and sections map to Jira work items and statuses. monday.com boards map to Jira spaces with items becoming work items and subitems becoming subtasks. Map each status, priority, and custom field to its Jira equivalent, and retire the ones nobody uses.
Atlassian has direct importers for both tools. The Asana importer maps tasks, sections, comments, and dates; custom fields carry over only from paid Asana plans. The monday.com importer brings items, subitems, files, and dependencies, but formula, mirror, and board relation columns are not supported.
If you choose not to import members, the Asana importer leaves user fields unassigned and changes commenter names to Anonymous. Import members as part of the pilot and check that assignments resolve correctly.
Compare item counts, attachment totals, and field values between the source and the Jira target. Log every discrepancy and fix field maps before the next wave. What you learn on the pilot team becomes the runbook for everyone after.
Every migration partner talks about data. Fewer talk about who can see it once it lands. If you set up identity after the move, you spend weeks cleaning up permissions that were wrong from day one.
Atlas Bench designs identity before any data moves. That means verified domains, claimed Atlassian accounts, SAML SSO, and SCIM provisioning from your directory are live on the target before the first import runs. People land in the right groups from the start, and offboarding closes every access path.
Atlassian Guard Standard (included in Enterprise plans) is the product that connects your identity provider to Atlassian Cloud. Without it, SAML and SCIM are not available, and user management falls back to manual administration.
A migration without governance becomes the same accumulated estate within a year. Governance means named owners for every Jira space and Confluence space, a process for creating new ones, and a regular access review that produces evidence.
Atlas Bench organizes this work in four layers that are load-bearing from the bottom up: L1 Identity and Access, L2 Platform and Migration, L3 Governance and Change, and L4 Agents and Automation. A migration lives at L2, but the identity and governance layers beneath and above it are what make the result hold.
Change control matters here because Confluence spaces and Jira permission schemes can drift quickly if anyone with admin access can modify them. Connecting permission changes to a change record in Jira Service Management closes that gap.
Atlassian certifies Solution Partners with specializations in Cloud Migration and Service Management, among others. A Cloud Migration specialization means the partner has met competency, capability, and customer satisfaction requirements verified by Atlassian. Check the Atlassian Partner Directory listing for each candidate.
If the partner's plan starts with data and treats identity as a follow-on, the migration will carry today's permission problems into the new platform. The partner should show you a clear plan for SSO, SCIM, group design, and how offboarding works on day one.
A migration is not done at go-live. Ask about hypercare, documentation, administrator training, and who owns the permission model afterwards. A partner that hands you the keys and walks away leaves you with an estate nobody knows how to run.
Every source tool has fields and structures that Atlassian's importers do not support. Trello checklists and custom fields do not import into software spaces. ClickUp rollups and comment replies stay behind. monday.com formula and mirror columns are not supported. The pilot import is where you discover these gaps and decide how to handle them.
Without governance, new Jira spaces and Confluence spaces get created with open defaults, and sharing settings slowly return to the per-board, per-folder model you left behind. Prevent this by connecting space creation to a standardization and governance process from day one.
People who were comfortable in their old tool will resist the new one if they cannot find their content or understand the new structure. Run change management alongside the migration, not after it. Atlas Bench measures change management programs by adoption rather than by go-live, because a migration succeeds when people use the new system, not when the data arrives.
Atlassian Guard Standard is the product that enables SAML SSO and SCIM provisioning in Atlassian Cloud. Without it, you cannot connect your identity provider, and user management falls back to manual administration. Enterprise plans include Guard Standard.
Guard also provides centralized audit logging, API token controls, and enforced two-factor authentication. For a migration, it means you can verify your domain, claim all user accounts with that domain, and provision groups from your directory before data moves.
Setting up Guard before the first import run is the single step that prevents the most post-migration permission cleanup. When accounts are claimed and groups are synced, every import lands in the right access model instead of a temporary state you have to fix later.
Inventory every tool, site, board, and workspace in scope. Map each one to a Jira space, a Confluence space, an archive, or retirement. Plan identity: verified domains, claimed accounts, and synced groups. Produce the target design and a wave plan.
Run a test import for one team per source tool. Compare every import against its source. Fix field maps, page trees, and permissions. Produce the runbook that every subsequent wave will follow.
Move teams on a published schedule. Each wave includes a short freeze on the source tool, the import, a reconciliation check with the content owner, and sign-off. After sign-off, the old tool goes read-only and then gets retired.
Retirement is not optional. Leaving old tools active means accounts and licenses continue accumulating in places nobody monitors. Each retired tool should have a documented retirement date, a read-only archive window, and a confirmed decommission timeline.
We design access before anything moves. Every person gets an Atlassian account your company manages before their work arrives. Domains are verified, accounts are claimed, and groups are synced from your identity provider before the first import runs.
We use Atlassian's importers where they exist and plan export and import where they do not. There is no Atlassian importer for SharePoint, so SharePoint content moves by export plus import, or through a Marketplace app when the volume calls for one.
We organize each engagement around the Stack: identity (L1), platform (L2), governance (L3), and agents (L4). A migration sits at L2, but L1 is always the first thing we stand up. Rising Star Partner of the Year, Americas, 2026 is how Atlassian recognized that approach.
The move to Confluence and Jira is not a data transfer. It is a chance to design the access model you should have had all along. Start with identity, design the target structure before anything exports, run pilot imports to catch gaps early, and retire old tools as each wave signs off.
If you want a partner that treats identity and governance as part of the migration scope rather than a follow-on, start with a free Jira health check from Atlas Bench.
No. Confluence imports Word files, Google Docs, Notion, and zipped HTML, but SharePoint has no direct Atlassian importer. Content moves by export and import or through a Marketplace app when the volume requires one. Atlas Bench plans the export route and runs a pilot import before full migration.
The Asana importer maps tasks, sections, comments, start dates, and due dates to Jira work items. Custom fields carry over only from paid Asana plans. If you skip importing members, user fields show as unassigned and commenter names become Anonymous.
You do not copy old sharing settings. Atlas Bench designs permissions from identity provider groups synced to Atlassian Cloud through SCIM. Groups are edited in one place, and every person lands in the correct space roles from day one.
Yes. Atlassian's monday.com importer brings items, subitems, files, and dependencies. Formula, mirror, and board relation columns are not supported. Atlas Bench runs a pilot import to confirm what carries over and documents the gaps before the next wave.
Timeline depends on the number of source tools and the size of the content, not on data volume alone. A typical engagement runs 10 to 16 weeks: 2 to 3 weeks for inventory and design, 2 to 4 weeks for pilot imports, and the rest for waves and retirement.
Keep a read-only archive of the old tool for anything the importer does not bring over. Decide during the pilot what history belongs in Jira or Confluence and what stays in the archive. Atlas Bench documents every gap so nothing is lost without a deliberate decision.