Skip to main content

Migrate your repository to iGrafx Cloud

Move your on-premises repository into your iGrafx Process360 LiveProcess360 Live iGrafx's cloud platform for end-to-end process management — combining process design, mining, simulation, and automation in a single environment. Cloud instance. The repository content arrives unchanged; you set up users, sign-in, roles, and licenses again in the Cloud.

Prerequisites​

  • An iGrafx Cloud subscription and an open migration ticket with iGrafx Support.
  • Platform version 19 or later on-premises. If yours is older, upgrade the platform before migrating.
  • Every user account, including test and service accounts, has a valid, unique email address as its username, or you have a mapping from each username to one. Item permissions, resource links, and governance roles carry over only for usernames that match.
  • Access to the database server that hosts the repository database, to export it. The iGrafx platform administrator role doesn't include this; you need whoever administers your SQL Server.
  • Administrator access to the Cloud instance. iGrafx provisions it at the start of your subscription and invites the contact named on the provisioning checklist first.

Migration strategy​

The migration runs in three phases and a cutover. Phase 1 configures your Cloud instance, which needs none of the migrated data, and Phase 2 prepares the on-premises repository. Phase 3 is how you back up and upload the repository database.

What transfers is the repository database only. Migrating to iGrafx Cloud lists what arrives unchanged and what you set up again.

Before you start: review the Rollback / backout procedure below.

Phase 1: Configure your Cloud instance​

Configuring the Cloud first gives you time to set up single sign-on and shows you what to prepare on-premises in Phase 2. Finish this phase before you upload a backup. When iGrafx registers the repository, it matches users, groups, and item roles by name against what exists in the Cloud, and removes the item permissions, cycle-group memberships, and resource links that don't match; see Migrating to iGrafx Cloud.

  1. Set up sign-in and user provisioning; see Setting up Single Sign-On and Synchronizing your user base. Cloud usernames are email addresses. In Phase 2, you change your on-premises usernames to the same email addresses, or provide a file so that iGrafx renames them during the migration. Use the same spelling and case, and give each group its on-premises name.
  2. Set up security roles; see Assign security roles. Use the roles iGrafx ships or recreate your on-premises server and repository roles. Recreate your item roles with exactly their on-premises names, because item permissions refer to them by name. Leave the roles reserved for iGrafx unchanged.
  3. Assign licenses.
  4. Copy the customizations you want to keep from your on-premises platform: email templates, localized property names, and, under Customize the platform, dynamic links, the narrative export theme, and the User Display Names format. Set the format before you create resources for users in the Cloud, because the platform names those resources in that format.
  5. Set up email.
  6. Generate API keys for your integrations; see Access the REST API. You connect and test the integrations after the final migration.

Phase 2: Prepare the source repository​

  1. Change every on-premises username to the email address the account uses in the Cloud. Every account needs its own valid email address, including test accounts and service accounts, so decide what to do with inactive accounts, accounts without an email address, and accounts that share one. If you can't change usernames on-premises, build a spreadsheet that maps each username to its Cloud email address instead; you provide it with the administration database in Phase 3, and iGrafx applies the mapping during the migration. This may incur a service fee.
  2. Decide whether to keep the repository short name. Changing it during the migration has no additional effect on links, because the new hostname already changes every URL.

Phase 3: Back up and upload​

Run these steps for each migration: for a test migration, if you agreed on one, and for the final migration at cutover.

  1. Export the repository database as a bacpac file. If the export fails because a service account or user account is bound to the database, clone the repository database, remove that account from the cloned repository database, and export the clone instead.
  2. Restore the bacpac file into a new, temporarily named database to confirm its integrity.
  3. Upload the file through the upload link iGrafx Support gave you in your migration ticket, following the instructions there.
  4. If you built a username mapping in Phase 2, upload the administration database and the mapping spreadsheet the same way.
  5. Confirm in the ticket that the upload is complete.
  6. iGrafx Support restores your repository and updates the ticket.

Test migration (optional)​

A test migration restores your backup into the Cloud instance before the final migration, so you can check the result and fix anything in Phase 1 or Phase 2 while the on-premises platform stays in use. The final migration replaces the test repository.

Agree on a test migration with iGrafx Support in your migration ticket, when you plan the migration or at the latest once Phase 2 is complete.

  1. Switch off Email Notifications in the Cloud instance under Admin → Email Management; see Manage email. Otherwise the users you've provisioned receive notifications from the test repository as well as from the on-premises platform. Switch it on again when you verify the final migration.
  2. Back up and upload the repository database as described in Phase 3. Users keep working on-premises.
  3. When iGrafx Support has restored the repository and updated the ticket, check the restored repository against the Verify checklist, except the Email and Integrations rows, which you check only after the final migration. Changes made on-premises after the backup aren't in it.

Cutover​

At cutover, iGrafx restores your final backup as your live Cloud repository. Changes made on-premises after the final backup aren't in it, so iGrafx recommends limiting the on-premises platform to viewing from the final backup until you've confirmed the migration. Users can still read everything.

  1. Agree on the final migration window with iGrafx Support.
  2. Tell users when the change freeze starts, that the platform stays readable, and when to expect the new URL. Ask desktop client users to check in before the freeze, so their changes are in the final backup.
  3. When the freeze starts, export the repository database as a bacpac file and upload it as in Phase 3.
  4. Limit the on-premises platform to viewing. Do this immediately after the backup, because any edit made on-premises after it isn't included in the migrated backup. One way is through item permissions on the repository's root folder, which every item below inherits: open the root folder's Permissions tab, note the current assignments under Item Role Assignments so you can restore them, then select the Everybody group, keep Viewer, and remove Author and any other role that grants editing. Do the same for every other user or group assigned there. Users who hold Set Any Item Permissions at repository level can still change item permissions, so leave that permission only with people who know that nothing changes during the freeze.
  5. Confirm the upload in the ticket. iGrafx restores the backup, registers the repository in your Cloud instance, and tells you in the ticket when it's ready.

Verify​

Walk through the migrated repository and compare it with your on-premises platform.

AreaWhat to confirm
FoldersThe folder hierarchy and item counts match the source
DiagramsDiagrams open, including approved and historical versions
DocumentsDocuments open
ObjectsObjects, properties, and relationships are present
Resources and RACIResources, organizations, and RACI assignments are connected to the right processes, and users are still linked to their resources
GovernanceCycles, cycle groups, approvals, and acknowledgments are present with their history
PermissionsUsers and groups have the expected repository and item access
LicensesUsers hold the licenses you assigned
Sign-inUsers sign in through single sign-on or with their new password, and accept the Subscription Services Agreement on first sign-in
Landing pagesPages display for each audience
LinksRepository links resolve; links to external systems are reachable
SearchMigrated content appears in search results
EmailWith Email Notifications switched on, a test notification arrives
CustomizationsEmail templates, localized property names, dynamic links, and the narrative export theme are in place
IntegrationsPointed at the Cloud hostname with their new API keys, integrations work

When everything is as expected, confirm the migration in the ticket. iGrafx then closes the migration, and the Cloud instance is your live platform. Any difference you find goes in the ticket as well.

Then update the links in your content that contain your on-premises hostname. Replace each with a repository link where you can, otherwise with the Cloud hostname. Do this only in the final Cloud repository: changes made in a test repository are replaced by the final migration. See What effect does changing the site URL have on my content.

Finally, tell your users: the new URL, that bookmarks and saved links with the old hostname need updating, that links in notification emails received before the migration lead to the old platform, and that they accept the Subscription Services Agreement the first time.

Rollback / backout​

Your on-premises platform is still running and is your rollback path.

  • Keep the on-premises platform available but limited to viewing until you've confirmed the migration, so nothing is edited in both places.
  • If verification fails, report the differences in the ticket and keep working on-premises until they're resolved. To work on-premises again, restore the item role assignments you noted on the root folder's Permissions tab. Changes you make on-premises after the final backup need a new backup and upload.
  • Decommission the on-premises platform only after you've confirmed the migration, and keep its final backup.