Information for Skuid pages migration

Hello Jesus,

The best starting point is this documentation:
https://docs.skuid.com/latest/appdev/en/skuid/deploy/salesforce/org-to-org.html

If you encounter any issues or confusion, don’t hesitate to reach out to support at customer.nintex.com!

Yes—Skuid pages can be migrated between Salesforce orgs using Page Packs, with supporting Salesforce components and configuration moved separately. The approach depends on whether the orgs are connected sandboxes/production or completely independent orgs.

Official documentation

• Skuid: Sandboxes and Connected Orgs⁠ — Overall deployment process, dependencies, page assignments, and post-deployment configuration.
• Skuid: Page Packs⁠ — Instructions for packaging, downloading, uploading, and unpacking pages.

Recommended process

1. Prepare the destination org. Confirm Skuid version compatibility, licensing, and user permissions. Inventory the objects, fields, code, and other resources the pages depend on.
2. Package the pages. Group related pages into a module if useful, then create a Page Pack. Include any principal pages required by dependent pages.
3. Move supporting components. Include required Salesforce metadata, Visualforce pages, images, JavaScript, and CSS. Export custom design systems separately.
4. Transfer and unpack. For connected orgs, use change sets to move the static resources and supporting metadata, then unpack the pages. For independent orgs, download/upload the Page Pack JSON and deploy the Salesforce metadata separately.
5. Restore configuration. Recreate modules and applicable data-source/component-pack settings; restore page assignments and overrides.
6. Validate before release. Test functionality and access in the destination sandbox before production rollout.

Best practices and migration considerations

• Back up destination pages first. Importing pages with matching module and page names can overwrite their current definitions.
• Page Packs do not carry the source pages’ revision history into the new org.
• As a practical validation checklist, review hard-coded record IDs, org-specific URLs, field API names, authentication, and navigation. Test as representative end users, including viewing, creating, and updating records.

One documentation caveat: Skuid’s org-to-org guide still references the Ant Migration Tool for independent orgs. Salesforce retired that tool in Spring ’24 and recommends Salesforce CLI for metadata deployment. Salesforce’s replacement guidance⁠.

From ChatGPT