Clean up your instance before migration

A cloud migration is a good opportunity to clean up your data in Server or Data Center and move to a cleaner slate in the Cloud. The more data you need to migrate, the longer and more complex your migration can become. Cleaning up your instance before running a test migration can result in a smoother migration, fewer performance issues, and productivity gains in the Cloud.

Don’t attempt to clean up your instance while a migration is running

The best time to clean up your data in Server or Data Center is before you run a migration. Cleaning up your data while a migration is running can cause the migration to fail.

Clean up your Jira instance

Test your changes and create backups

Some of these cleanup activities may affect your entities in Jira, or the instance in general. Test your changes on a staging environment first. Make sure to also create a backup of your production instance before applying them.

Review your Jira data

Check for and fix any duplicate email addresses. This is a mandatory preparation step as duplicate email addresses are not supported by Jira Cloud.
Check for and fix any conflicts with group names in Server/Data Center and Cloud. This is a mandatory preparation step as groups with identical names will be merged in Jira Cloud.
Check for and remove any unused apps or trial data.
Make a list of projects that you want to migrate, and remove projects you don’t need before migrating.
Check how much data you have (for example, the number of projects or custom fields) and consider reducing its size or complexity. You can view this data by going to Administration > System > System info. Data could include:
- Number of projects
- Number of custom fields
- Number of workflows
- Number of screens, issue types, permission schemes
- Number of users
- Number of inactive users
Use Marketplace apps like Optimizer for Jira to help you assess current usage and clean up your system.
Use the Database Integrity Checker (native to Jira Server) or the Integrity Check for Jira Marketplace app to check the state of your data.

Some customers choose to delete all their data and migrate only configuration and empty project containers. This may be a good option if you're planning to start fresh in the Cloud, but would like to keep your Server configuration. Learn more about cleaning up your Jira instance

Optimize your database

Optimize your database by using built-in features that clean up the tables, indices, or statistics. Below, we included commands for the most common databases, together with the biggest Jira tables.

PostgreSQL

vacuum full jiraissue;
vacuum full jiraaction;
vacuum full changegroup;
vacuum full changeitem;
vacuum full worklog;
vacuum full customfieldvalue;

PostgreSQL documentation

MySQL

optimize table jiraissue;
optimize table jiraaction;
optimize table changegroup;
optimize table changeitem;
optimize table worklog;
optimize table customfieldvalue;

MySQL documentation

Microsoft SQL Server

update statistics jiraissue;
update statistics jiraaction;
update statistics changegroup;
update statistics changeitem;
update statistics worklog;
update statistics customfieldvalue;

Microsoft SQL Server documentation

Oracle

analyze table jiraissue compute statistics;
analyze table jiraaction compute statistics;
analyze table changegroup compute statistics;
analyze table changeitem compute statistics;
analyze table worklog compute statistics;
analyze table customfieldvalue compute statistics;

Oracle documentation

Some of these features run automatically (like auto-vacuum), which already optimizes performance. Running them manually can still be beneficial for large database operations that happen during migrations.

Minimize your Jira data customizations

Standardize custom workflows to reduce data complexity before migration.
Review groups and permission schemes to see which aren’t being used, and if there are opportunities to standardize or simplify those that are being used.
Streamline custom fields, schemes, issue types, statuses, resolutions, boards, filters, and screens. Below are some Jira queries you can use to help you clean up your instance:

These are sample queries and may require some additional tweaking or testing in your own specific environment. Contact a database administrator in your organization for additional assistance. Some of these queries may take a long time to run in large instances with millions of rows. Run these with caution, ideally on your testing environment first.

Custom fields which are not used

select customfield.id
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
where customfieldvalue.stringvalue is null and customfieldvalue.numbervalue is null and 
customfieldvalue.textvalue is null
order by customfield.id

Custom fields which have low usage

select customfield.id, count (*)
from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield
group by customfield.id having count (*) < 5
order by count (*) desc

List custom fields that have not been updated after date (YYYY-MM-DD)

select field.id, field.cfname from customfield field where field.cfname not in (
select item.field from changeitem item 
JOIN changegroup cgroup ON item.groupid=cgroup.id 
where item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD'
) and customfieldtypekey not like '%com.pyxis.greenhopper%' 
and customfieldtypekey not like '%com.atlassian.servicedesk%'
and customfieldtypekey not like '%com.atlassian.bonfire%'

User activity related to a custom field (using the complete custom field id. Ex: customfield_10301)

select id, entitytype, entityid, username, to_timestamp(lastviewed/1000) 
as lastviewed, data from userhistoryitem 
where entityid='customfield_10001'
order by lastviewed desc;

List all select-list type custom fields

select * from customfield 
where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select';

List all custom fields along with the options

select cf.id, cf.customfieldtypekey, cf.cfname, cfo.sequence, cfo.customvalue from customfield cf
join customfieldoption cfo on cfo.customfield = cf.id
where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select'
order by cfo.id, cfo.sequence;

Filters which contain a "Custom Field Name" or custom field id "10001"

select * from searchrequest where reqcontent like '%Field Name%' or reqcontent like '%10001%';

Workflows that reference a custom field

select * from jiraworkflows wf where wf.descriptor like '%customfield_10281%';

Fields with a global context

SELECT distinct(p.pkey),
cfname,
cf.id,
p.pname                          
FROM CUSTOMFIELDVALUE cfv
left join JIRAISSUE ji
on cfv.ISSUE = ji.id            
right join CUSTOMFIELD cf
on cf.id = cfv.customfield
left join project p
on p.id = ji.project
WHERE cf.id in (''' + globalContextIdsCommaSeparated+ ''')
GROUP BY cf.id,cf.cfname,p.pkey, p.pname
ORDER BY cf.cfname,p.pname

Non-calculated fields with contexts & no values that do not have Screen/Workflow/Notification schemes

SELECT
cf.id id,           
to_char(min(ji.created), 'YYYY/MM/DD'),
to_char(max(ji.updated), 'YYYY/MM/DD'),
count(distinct(ji.id))
FROM CUSTOMFIELDVALUE cfv
left join JIRAISSUE ji
on cfv.ISSUE = ji.id            
left join CUSTOMFIELD cf
on cf.id = cfv.customfield            
GROUP BY cf.id
ORDER BY cf.id

Non-calculated fields with contexts, no values, and do not have Workflow/Notification scheme, but are mapped to some screens

SELECT
cf.id id,           
to_char(min(ji.created), 'YYYY/MM/DD'),
to_char(max(ji.updated), 'YYYY/MM/DD'),
count(distinct(ji.id))
FROM CUSTOMFIELDVALUE cfv
left join JIRAISSUE ji
on cfv.ISSUE = ji.id            
left join CUSTOMFIELD cf
on cf.id = cfv.customfield            
GROUP BY cf.id
ORDER BY cf.id

Audit custom field misuse

This is a potential query to assist in extracting how custom fields are being used so that you can identify any fields that are being used for alternative purposes, or are just being misused.

select 
  customfield.id, 
  customfield.cfname, 
  customfield.description, 
  customfieldvalue.stringvalue,
  customfieldvalue.numbervalue,
  customfieldvalue.textvalue,
  customfieldvalue.datevalue
from customfield 
left join 
  customfieldvalue on customfield.id = customfieldvalue.customfield
where 
  customfieldvalue.stringvalue is not null or
  customfieldvalue.numbervalue is not null or
  customfieldvalue.textvalue is not null or
  customfieldvalue.datevalue is not null
group by customfield.id, customfield.cfname, customfield.description;

Deleting custom fields can also delete associated data.

Be careful when updating or removing shared configuration entities, such as Issue types, Workflows, Custom fields and Schemes from your Server instance if you’re planning to migrate additional projects that share these entities later down the track.

Use Jira Cloud Migration Assistant

The Jira Cloud Migration Assistant can help you leave behind data you don’t need in the Cloud. You can it to perform the following pre-migration techniques:

Sort projects by Last updated on the project selection screen. This can help you focus on which projects to migrate before others.
Migrate archived projects either ahead or after the migration so you don’t increase migration downtime for the active projects that matter to current users.
Generate a pre-migration report to review your data.

The Jira Cloud Migration Assistant doesn’t migrate all the configurations from your Jira Server or Data Center instance to the Cloud. It performs an analysis of what’s needed for the projects you’ve selected, and only migrates what’s necessary for those projects to continue working in the Cloud. This means that any unmapped or unused configurations like workflow schemes, permissions schemes, and custom fields that aren’t used by the projects you’ve selected are not migrated to the Cloud. Learn more about the Jira Cloud Migration Assistant

Clean up your Confluence instance

Test your changes and create backups

Some of these cleanup activities may affect your entities in Confluence, or the instance in general. Test your changes on a staging environment first. Make sure to also create a backup of your production instance before applying them.

Review your Confluence data

Check for and fix any duplicate email addresses. This is a mandatory preparation step as duplicate email addresses are not supported by Confluence Cloud.
Check for and fix any conflicts with group names in Server/Data Center and Cloud. This is a mandatory preparation step as groups with identical names will be merged in Confluence Cloud.
Remove any unused apps or trial data.
Check for and consider removing anything that hasn’t been used recently, such as specific pages, entire spaces, attachments, macros, or apps. Learn how to gather usage statistics

Some customers choose to delete all their data and migrate only configuration and empty space containers. This may be a good option if you're planning to start fresh in the Cloud, but would like to keep your Server configuration. Learn more about cleaning up your Confluence instance

Minimize your Confluence data customizations

Below are some Confluence queries you can use to help you clean up your Server/Data Center instance:

Query to return statistical results for Content Creation, per user

select content.creator, cwd_user.display_name, count(content.contentid) as total_content_created 
from content 
inner join user_mapping on content.creator = user_mapping.user_key 
inner join cwd_user on user_mapping.username = cwd_user.user_name 
inner join spaces on content.spaceid = spaces.spaceid 
where contenttype = 'PAGE' and content.creator is not null and content_status = 'current' 
and prevver is null 
and content.creationdate between '2018-07-01' and '2019-01-01' 
group by content.creator, cwd_user.display_nameorder by total_content_created DESC

List last modification date for each space in a given time:

SELECT spaces.spacename, spaces.spacekey
FROM content, spaces
WHERE content.spaceid = spaces.spaceid
GROUP BY spaces.spacename, spaces.spacekey
HAVING MAX(content.lastmoddate) < '2006-10-10';

Next steps

After you’ve cleaned up your instances, review the following pre-migration checklists to get ready for the migration:

More information and support

We have a number of channels available to help you with your migration:

for migration planning information, visit the Atlassian Migration Program website
for technical issues or support with strategy and best practices, get in touch with our support team
for peer advice, ask the Atlassian Community
for expert guidance, work with an Atlassian Partner

Was this helpful?

It wasn't accurate

It wasn't clear

It wasn't relevant

Still need help?

The Atlassian Community is here for you.

Ask the Community