Mass / Bulk Migration from V1 to V2 pages?

Hello Mark,

I’m glad to hear you’re looking into upgrading! The V1 to V2 migration is tightly bound to the page list, so there’s no bulk equivalent available. I feel like your best bet is probably to script the UI navigation so you don’t have to do all the migrations manually.

You’ll still have to adjust things like page includes manually, but you may have able to make that a bit easier with skuid-sfdx since it’ll be easier to do locally through the XML than it would be through the builder.

Hi ​@Mark L 
Has your question been answered? 

I did some investigating and it would appear there is no way for us to do any sort of bulk migration or even manual one-by-one migration. We utilize javascript, custom css, and other tweaks in our implementation all of which do not translate to V2 at all, and would need complete page rewrites to function. That’s a non-starter right there. I also tried converting simpler pages that did not have these problematic elements in them and that did not work properly either. I ended up having serious display logic bugs in the pages I was experimenting with conversion to V2.

It looks like it will just not be possible to convert to V2 unless we completely rewrite our implementation. This is extremely distressing. If V1 ever stopped being supported entirely to the point where we could no longer use it, we’d be dead in the water with a year or more of work to do to recover. I also noticed it’s no longer possible in the latest version of Nintex for Salesforce to create new V1 pages. Pages default to being created in the new Nintex editor. I had to program in an APEX trigger to force new pages created to be V1 in order to be able to create new V1 pages.

That said, I see that Nintex created an even newer page editor that appears to be the new standard that uses an even newer version of pages than V2 pages that is also not compatible with V2 pages. This is also distressing. Nintex apps for Salesforce (previously SKUID) seems to foster an environment that is not being maintained with backwards compatibility in mind. Each new iteration of the designer is not compatible with the old system, causing any work you’ve done in the old system to become legacy, requiring you to start over in the new system if you want to be up to date with a supported tool set. This is a worrying practice; as a designer/builder I can never trust anything I build to last in perpetuity, as design systems seem to be replaced every few years with new backwards-incompatible design systems requiring rewrites of any pages created in the old systems.

Hi Mark,
Thank you for laying this out so clearly, and for all your contributions to the community over the years. I hear how stressful this feels—especially with such an extensive implementation. A few points and practical next steps:

• Recap. As you discovered, there isn’t a one-click path from V1 → v2 (legacy composer) → v2 (Page Designer).  While a mass migration utility would be ideal, the fundamental architectural differences between versions mean that custom code would still need individual assessment and rewriting - which, as you've discovered, is a significant undertaking. Nintex Apps for Salesforce Docs

• Why rebuild. V2 has been GA for five years and keeps expanding its declarative features. Many behaviors that once required JS in v1 are now doable declaratively in v2, reducing long-term maintenance risk (even though the initial lift is real). We’re actively working on embedding AI features into the build experience to make it faster than ever to build pages.

  • What Page Designer is. It’s the latest build experience for v2—not a third runtime.  

• When will v1 be deprecated? Platforms do evolve, but if we plan any v1 deprecation, we’ll communicate with reasonable lead time so you can plan an orderly transition.

Suggested path forward:

1. Try the Page Designer for new pages.
   Check out learn.nintex.com for courses introducing key concepts. 
    

2. Run an “upgrade lane.” (e.g., 1–2 pages per month or whatever cadence works for you) Start with the simpler, self-contained pages and the move on to the high priority but more complex pages.

Resources:

• V2 Page API Migration Utility (what auto-converts vs. what stays manual). Nintex Apps for Salesforce Documentation

• Migration checklist (Part 1 & 2)—step-by-step approach, including custom component/JS guidance. Part 1 & Part 2

• Page Designer overview: ​​​​​​​Documentation
   

I know rebuilding your application will be a significant undertaking and require considerable time and resources. I encourage you to consider it to put your implementation on a supported, less-brittle foundation. Please know that your feedback about the migration challenges and backwards compatibility concerns is valuable and helps inform our product decisions going forward.

Best,
Anna Tadros
Product Manager, App Design & Nintex Apps for Salesforce​​​​​​​