Developer
Get Support
Sign in
Get Support
Sign in
DOCUMENTATION
Cloud
Data Center
Resources
Sign in
Sign in
DOCUMENTATION
Cloud
Data Center
Resources
Sign in
Last updated Jan 14, 2026

What is Id Mapping?

Overview

After you perform a Server or Data Center to Cloud migration (for Jira or Confluence), the IDs of entities change on the cloud site. The migration architecture is not designed to retain the original server or Data Center IDs on cloud.

Why do IDs change during migration?

When migrating from Server/DC to Cloud, the underlying architecture and data storage mechanisms are fundamentally different. Cloud instances use their own ID generation schemes that are optimized for cloud infrastructure, which means that existing IDs from your Server/DC instance cannot be preserved.

What entities are affected?

For Confluence:

Entity IDs that change after migration include:

  • pageId - Unique identifiers for pages
  • blogPostId - Identifiers for blog posts

For Jira:

Entity IDs that change after migration include:

  • issueId - Issue identifiers
  • projectId - Project identifiers
  • componentId - Component identifiers
  • customFieldId - Custom field identifiers
  • Other configuration identifiers

Impact on external integrations

If you have external integrations, scripts, or reports that reference content using these server/DC IDs, they may stop working after the migration completes. Common affected systems include:

  • Custom scripts that query Atlassian APIs using entity IDs
  • External databases storing references to Atlassian content
  • Third-party integrations that maintain ID mappings
  • Reporting tools that track content by ID
  • Automation rules that reference specific entities

The solution: Id Mapping

Id Mapping provides a mechanism to fetch mappings between your old Server/DC IDs and the new Cloud IDs. This allows you to:

  1. Identify corresponding entities - Find which Cloud ID corresponds to each Server/DC ID
  2. Update external systems - Replace stored serverIds with corresponding cloudIds
  3. Repair integrations - Fix broken references in external tools and scripts
  4. Maintain data integrity - Ensure your external systems continue to work with migrated content

Typical repair workflow

A typical fix involves:

  1. Generate Id Mappings - Use the Id Mapping APIs to create a report
  2. Download the mapping file - Get the complete mapping between old and new IDs
  3. Update external systems - Replace all stored serverIds with corresponding cloudIds
  4. Test integrations - Verify that external tools now work with the new Cloud IDs

Next steps

Rate this page: