Page Designer Migration Utility
Note: This feature is currently in beta. There could be changes to its design, behavior, and functionality in upcoming releases.
The Page Designer Migration Utility updates existing page XML to work with the Page Designer, the latest drag-and-drop workspace for building experiences in Nintex Apps. Pages built in the previous build experience, known as the Composer, can be quickly migrated with various required changes made by the utility itself.
Migration is not currently required, but future development work will be focused on the Page Designer as opposed to the Composer. Pages that have not been migrated will continue to open in the Composer.
While the migration process itself takes little time per page, we encourage users to thoroughly test page functionality after running the utility. When planning migration timelines, account for the time required for a proper application lifecycle management process.
Migrate a page
Before you begin
Migrations are made in-place on the existing page, creating a new page revision. This means that anywhere the page is currently published will automatically update to reflect the migrated page.
End users should typically see no differences at runtime after migration. The migration utility only converts existing page structures, and it does not add or remove features.
Important: This is why it is strongly advised that you run this utility within a development environment, test migrated pages, and then deploy the migrated pages to a production environment.
If you wish to experiment with the Page Designer before migrating even in a development environment, consider cloning a page and using this utility on the cloned page.
Access the migration utility
The migration utility can be accessed in two ways:
- In the All pages list, click More Options > Migrate to Page Designer.
- In the Composer, click Migrate to Page Designer.
Pages must be migrated individually; there are no options for bulk page migration.
Address migration messages
Once a page is migrated, each change made by the utility to the page is noted as a migration message. These
migration messages are stored within a sliding panel that can be accessed by clicking the notification icon
(
) in the designer’s top toolbar.
Messages may appear for the following common migration changes. Messages can be removed by clicking Dismiss. Dismissing a migration message is considered a page change and must be saved by clicking Save.
Once all messages are dismissed, the migration list can be dismissed entirely by clicking Dismiss migration list and clicking Save.
Display logic conditions centralized
Previously display logic rules had to be accessed on each element they were applied to, but display logic statements are now centralized into a single tab within the Page Designer.
For more information, see Display logic .
Actions now live in action flows
All action lists and action sequences have been centralized into action flows. Action flows are built in a new node-based workspace, and they can more easily be reused across different interactions within a page.
For more information, see Action Flows.
Modals and sliding panels have been moved to Surfaces
The new Surfaces area in the Index is a way to manage the overlays within your page. Instead of keeping sliding panels and modals locked away in an action list, they now appear here—allowing for easier access and centralized organization.
Previously, modal footers could only contain buttons—functioning as a single button group. In the Page Designer, modal footers can contain any component.
For more information, see Page Designer Sliding Panels , or Modals .
Child relationships are now handled through dependent models
Previously, child relationships were selected as an additional feature of a single model. In the Page Designer, these nested relationships (and arrays) are now handled with dependent models, which are nested beneath a principal model.
Using dependent models, you can retrieve the same data and utilize other model features specifically for the selected child relationship.
Existing child relationship fields have been updated to use dependent models.
For more information, see Create and Configure Models .
All instances of “uniqueid” are now updated to “uniqueId”
To maintain capitalization consistency, all XML attributes that were previously uniqueid have been updated to uniqueId. Also, all references to uniqueid within this page’s properties
and snippets have been updated to reflect this new capitalization.
If you targeted uniqueid in any
components or snippets, check that your page still works as expected.
Revert a page migration
Because migrations are done in-place, no new pages are created during migration—instead, a page revision is created. If you are seeing issues with a page after migration, it can be helpful to revert to an earlier revision compatible with the Composer.
When a page is migrated, earlier revisions compatible with the Composer are grouped into a section labeled Built with Composer (Legacy). A named revision with this same label is created as well. Reverting to any revision within this grouping will cause the page to open in the Composer workspace as opposed to the Page Designer.
If a page is migrated, reverted, and migrated again, revisions are grouped by the workspace they are compatible with. A section header indicates whether the revisions following it are migrated to Page Designer or built with the legacy Composer.
For more information on working with revisions, see Page revisions.
Test and deploy a page
It’s important to note that page migration occurs in place, and if a page is published end users will immediately see any changes. Because of this, it’s important to use the migration utility in a development environment.
Migrating pages in a development environment allows you to thoroughly test the functionality of a page outside of a production environment, where end users are relying on a page to work with live data.