If you’re preparing a migration from SAP ECC to SAP S/4HANA, you probably already know it’s not just a case of “switching systems”. And if you’re also running OpenText Vendor Invoice Management (VIM), there’s a step you really shouldn’t skip: checking whether your current version is compatible with the new environment. Because no, not every VIM version fits with every S/4HANA release, and the jump can touch things you might not expect: components, features, OCR, or even custom developments you’ve relied on for years.
So it’s worth being clear from the outset: an OpenText VIM upgrade to S/4HANA isn’t simply about installing a newer version. The key lies in defining the right upgrade path and knowing in advance which parts of your current solution could be affected during the conversion.
How do you define the OpenText VIM to S/4HANA upgrade path?
It’s tempting to focus only on the target version. But knowing which VIM release is compatible with the S/4HANA version you’re heading towards is only part of the job. You also need a clear picture of where you’re starting from and what steps are needed to get there.
Depending on your current release, you may still need to meet certain prerequisites in ECC: reaching a minimum Support Package, adding specific components, or preparing the architecture beforehand. These requirements can shape the conversion and also influence how the SAP Maintenance Planner determines the target software stack.
It’s also worth reviewing aspects such as the components installed and certain licensing conditions, which can vary depending on whether your VIM was purchased through SAP or directly from OpenText.
In short: before starting the upgrade, confirm there’s a supported upgrade path between your current environment and the one you’re aiming for.
Deprecated functionality and mandatory changes in VIM
If your VIM solution has been evolving for several years, chances are it includes workflows, reports, approval models, posting mechanisms or configurations that have changed quite a bit in the current versions.
Identifying deprecated VIM functionality is an essential step. Some features will already have been replaced by newer alternatives; others will need adapting to fit the new environment.
And here’s the catch: even if your goal is a mostly technical upgrade, some changes simply aren’t optional. A good example is how certain uses of Business Rules have evolved towards Logical Modules, which also reflects how VIM’s internal processing model has changed.
The aim is to go into the conversion already knowing what needs replacing, what needs adapting, and what can stay as it is, rather than carrying old configurations across without first checking whether they fit the target version — and whether OpenText still supports them.
OCR, Intelligent Capture and learning
OCR and the learning associated with invoice recognition deserve special attention in any VIM upgrade. Depending on the source and target versions, the technology used, the way business entities are determined, the handling of existing learning, or the available training options can all change.
This is particularly noticeable when earlier solutions such as ICC/BCC evolve into Intelligent Capture for SAP (IES). In these cases, it’s not enough to think only about the technological shift: you also need to define how existing learning will be managed and how recognition will be validated in the new environment.
What’s more, current versions bring new training and extraction analytics capabilities, allowing you to act on specific suppliers, layouts or fields where recognition can be improved. So the upgrade doesn’t have to be just a technical migration of the OCR solution, it can also become the perfect opportunity to improve extraction quality and push the process further towards automation.
Custom developments and integrations: what’s worth keeping?
Custom developments are another area that needs looking at before deciding on the scope of the migration.
A customisation may depend on standard functions, transactions or behaviours that have changed in both VIM and S/4HANA. And sometimes the opposite happens: a requirement that once needed a custom development is now covered by standard functionality.
That’s why migrating every development “as is” isn’t always the best option. The upgrade is a good moment to review what needs adapting and where there’s room to cut back on customisations, simplify the solution and make future upgrades easier.
Should you use S/4HANA as a chance to review document archiving too?
For many organisations, the migration to S/4HANA is part of a wider strategy to modernise the SAP architecture and move towards cloud models. If that’s your case, it may also be worth using the moment to review your document management system, content server and archiving strategy.
When organisations decide to migrate historical documents to new repositories, one of the key requirements is making sure they remain accessible from SAP, both during and after the change.
At ImagineRight we have specific experience in document migrations and the evolution of archiving architectures in SAP environments. We also offer ArchiveLord, our SAP ArchiveLink-based solution for connecting SAP with different repositories, including cloud environments, to make document migration between them easier.
Preparing the VIM upgrade before starting the conversion
An OpenText VIM upgrade as part of a migration to SAP S/4HANA requires looking beyond just the target version. The upgrade path, prerequisites, deprecated functionality, OCR and existing developments can all influence both the conversion process and the final outcome.
Reviewing all of these points properly helps reduce risk and lets you use the migration as an opportunity to reach S/4HANA with a VIM solution that’s supported, simplified and ready to keep evolving.
