Preparation

Before you consider migrating Agile Hive from Server or DC to Cloud, make sure to read through Atlassians Cloud transformation guide | Atlassian first.

Installation and Configuration

Prepare your cloud site

1. Make sure to install the newest version of Agile Hive (see here for more information: https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/511082497) and create necessary Jira entities in the https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/511082635 of Agile Hive

2. Request a free installation link for the the Agile Hive Cloud Migration Helper app through raising a request on our service desk: https://seibert.link/ahc-help-cloudmigration including the following information:

   • Company: Name of your company (for partners: Company that plans to migrate)

   • Cloud Site: URL of the target Cloud site you’re migrating to

   • User: Current Jira Server / DC user tier & Cloud user tier

   • Migration Type: Sandbox or production?

3. Install the Agile Hive Cloud Migration Helper as described in “Installing private apps” on Install and manage app access | Atlassian Support:

   1. As a Jira administrator, navigate to the apps administration from the configuration menu

      Open

      

   2. Navigate to “Settings”

      Open

      

   3. Click on “Enable development mode”

      Open

      

   4. Click “Install a private app” from the menu on top

      Open

      

   5. In the modal window, choose “Jira” and enter the URL you received from the Agile Hive support. Then click ‘Install app’.

      Open

      

   6. After that the app should list in “Installed apps” (might need a reload)

      Open

      

Prepare your Server / DC instance

1. Install the newest version of the Jira Cloud Migration Assistant | Atlassian Marketplace

2. Enable the “migration dev mode” dark feature

   1. Determine your Jira base URL in the system settings under “Base URL”

   2. Navigate to <Jira_Base_URL>/secure/SiteDarkFeatures!default.jspa

   3. Enter migration-assistant.app-migration.dev-mode into the input field

   4. Click “Add” or “Submit”

   5. (You can disable the feature after migrating by deleting the migration-assistant.app-migration.dev-mode key again)

3. Make sure to have have the newest version of Agile Hive on your Server / DC instance

   1. you need at least version 3.64.3 to initiate a migration in general

   2. version 3.72.1 enables the migration of more data, like e.g. custom fields

4. With version 4.1.0, Agile Hive for Data Center supports Epics on all levels. That means, that hierarchical links between work items from the same project are possible. As this is not yet possible in Agile Hive for Cloud, make sure to migrate Agile Hive Epics first. Follow this article here: https://info.seibert.group/display/AGILEHIVE/Cloud+Migration+Prerequisites

Migration execution

Migration guide

1. Go to “System” and under “Import and Export” go to “Migrate to cloud”

2. Under “Assess” click “Begin assessing” and make sure to select “Needed in cloud” for Agile Hive Suite

3. Under “Prepare” click “Begin preparing” and then “Choose cloud site”

4. For “Migrate from” enter you base URL of the server instance and choose the destination cloud site in “Migrate to”

5. Check the “Allow Atlassian to access migrations data to perform your migration” checkbox and click “Confirm”

6. Back in the previous screen in “Connect to cloud”, choose the authorized cloud site from the dropdown menu and click “Continue”

7. Under “Install” Agile Hive may not appear as a required app for cloud (because as of Dec 5, 2024 Atlassian cannot handle privately listed apps (see https://jira.atlassian.com/browse/MIG-1787 for details), so just click “Continue” again

8. Under “Agree” Agile Hive should show up and the policy needs to be agreed

9. Click “Done”

10. Assess and prepare users and email domains according your needs, and maybe migrate your users in advance

11. Create a new migration

12. Provide a unique name for the migration, choose migration stage (Production or Testing) and make sure your target cloud site is selected

13. In the next step, select “Choose what to migrate” and select Projects according to https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/614268930/Agile+Hive+Migration+Guideline#General-migration-guidelines-%2F-advice

14. For “Advanced Roadmap plans”, “Dashboards, boards and filters” and “Users and groups” select options according your needs (data related to the project should be sufficient)

15. Make sure to select Agile Hive (or the option “All”) under “Apps” and click “Run pre-migration checks”

16. Fix potential errors in the list and click “Review migration” afterwards click “Run”

17. Back in the migrations dashboard, you can click on “View details” to examine the progress of the migration even further.

Manual migration steps

After a successful migration run (for a part of your organization), you need to follow these manual steps to recreate all possible data from your Server / DC instance, as not all Agile Hive data gets migrated automatically (yet):

1. Go to “My organization” and resemble the project hierarchy to match your Server / DC instance (see https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/512197703 for more information)

2. Check and update hierarchical links via ‘SAFe® Hierarchy’ panel in Jira Work Item Detail View for individual work items as needed.

3. Adjust your project configuration of Screens, Screen Schemes, and Work Type Screen Schemes to the Agile Hive default or adjust as needed (see https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/512164556 for additional information on recommended / minimum required configuration).

   • The “Milestone Date” custom field gets migrated automatically, but is not included in the Screens from Agile Hive Cloud. You can add the migrated field to the desired screens (where the Cloud version of the field should already exist), rename the Cloud field to something else and make sure that your migrated field is called “Milestone Date” (without any “migrated”-suffix). Now the Milestones should also appear in Agile Hive views like the Roadmap or in Reports

4. To maintain your set dependencies from Server / DC, go to the https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/512196895 and select the Work Item Link Type and Direction that you used before, and click “Save”.

5. Create your PIs as you need for the future

   • If you already had PIs planned for the future on you Server/DC instance, you can recreate the PIs with the same dates in the Cloud Solution Train and/or ART via https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/512165093. After that go to the Agile Hive Project Settings in each team project to map the iterations created in Cloud with the sprints, that were migrated from Server/DC. You should delete the newly created and empty sprints from Cloud again afterwards to avoid confusion.

6. Some calculated fields like PI Involvement or Teams Involved might be out of sync with the data after a migration. We are still working on a solution to handle this problem. Reach out to us to get support in this matter.

Handling large instances

You can try to migrate the whole instance at once. However, if you encounter problems reach out to us and read the following suggestions. The major concern is the amount of work items included in the migration. A couple of projects with around 100k work items show no problems. However, when dealing with several hundred of projects it might be advisable to split the migration into several parts if the migration shows errors:

1. Try to migrate parts of your organization with reasonable sizes, e.g. < 100k work items for all projects to migrate in one batch. Even though the migration helper app is built to handle a large amount of data, predictability, stability and migration speed will be better with reasonable sizes. Potential performance or stability issues do not depend on Jira entities alone, but on the amount of app data entities like custom field values in work items.

2. Try to not migrate all projects at once if you encounter problems during testing. It is better to migrate projects in the organization by subtrees from top to bottom. This means choose an ART and the parent solution and / or portfolio project and include all teams beneath this single ART. Then migrate the next ART with the same approach until the whole organization is migrated.

   Open

   

   Example of migrating a subtree when dealing with a large organization of a couple of hundrets projects

After the migration

After all projects are successfully migrated you can do the following things on your Cloud site

• Delete the Work Item Link Type, that was used on Server / DC for managing the Work Hierarchy (as in Cloud, the Work Hierarchy is managed through Work Item properties, see https://agilehive.atlassian.net/wiki/spaces/CLOUD/pages/512164965) – by default, the Work Item Link Type is called “Agile Hive Link”