Migration guide
For customers, partners and consultants planning a move from InterForm400 to InterformNG2.
InterformNG2 is a new product, not a new version of InterForm400. That shapes everything about how you plan the move: this is a conversion project, not an upgrade. The good news is that it is a well-trodden path, and most of the effort sits in a few predictable places.
Most InterForm400 setups were not designed in one go. They grew. Twenty years or more, several ERP upgrades, and a series of people who each added what was needed at the time - overlays, queues, exit programs, a script here and there. Very little of it was written down.
That is where the real risk in a conversion project sits. The person who knows why a particular queue splits the way it does, or what that one exit program actually corrects, is often close to retirement or has already left. When the knowledge lives with one or two individuals, they become a bottleneck: every question in the project waits for them, and if they leave partway through, you are reverse-engineering behaviour from printed output.
Worth confronting at the start rather than discovering in month three. Two things help: document the current setup while the people who built it are still available, and use the conversion to move that knowledge into the team instead of rebuilding the same dependency in InterformNG2.
Here is how we recommend approaching it.
Almost every InterForm400 installation contains more than anyone remembers. Overlays built for a document that no longer exists, queues nobody has touched in years, exit programs written by someone who left a decade ago.
Two things make this visible:
The last-used dates are usually the most valuable output. It is common to find that a large share of overlays and queues are dormant, which means they never need to be converted at all. That is the cheapest scope reduction available.
A conversion is a rare chance to clean up. Worth deciding early:
For several ERP systems we offer predefined InterformNG2 packages - ready-to-use workflows and templates for the standard documents, built to work with that ERP. Using a package as your base is usually the fastest route to a simpler setup: you start from a clean, maintained design instead of an empty system or a copy of what you have today, and you only build what is genuinely specific to your business. Available packages and their documentation: Interform Solutions and Packages
You can keep feeding InterformNG2 spool files, which is the shortest path and leaves your ERP untouched. Or you can work from XML, which makes conditional logic, e-invoicing and future ERP changes considerably easier. Many companies take the opportunity to modernise their IBM i programs so they generate XML natively. If that is not practical, our Spool2XML Module converts your existing spool output into XML instead, so you can still work data-driven without changing the programs.
InterformNG2 has a single template format, and shared headers and footers can be reused across documents. Many installations move to the new setup with noticeably fewer templates than they have today.
Much of what needed a user-exit program in InterForm400, such as producing PDFs with index files for archiving, is now built into InterformNG2. Where custom logic is genuinely required, it moves to XPath or scripts inside InterformNG2 rather than external programs on the IBM i.
Because InterformNG2 is a different product, your InterForm400 overlays cannot simply be moved into it. The template format is new, and templates are built in the InterformNG2 designer.
We do have a Template Converter that generates an InterformNG2 template from an InterForm400 overlay, and it can also work from a PDF, optionally with a matching XML file for data mapping. Things to know about it:
For an overlay conversion we need the full overlay export including sub-overlays and fonts, a matching spool file, and ideally a PDF of the current output so we can cross-check the result.
So you have three routes per document: start from the predefined package for your ERP, convert the existing overlay and refine it, or build it fresh in InterformNG2. Documents with a fixed, heavily approved layout tend to suit conversion. Documents you were planning to redesign anyway are usually better taken from the package or built fresh.
Conversion projects vary widely. We have completed straightforward ones in around two weeks. We have also worked with setups grown over twenty years, with hundreds of templates and heavily customised processes, where the project ran over several months.
What drives the difference is mostly the number of documents genuinely in scope, how much customisation sits outside the standard product, and how quickly your team can review and approve output. The analysis in step 1 is what turns this from a guess into a plan.
Two good places to start: