When businesses embark on integration projects, whether migrating from SAP PI/PO to Integration Suite or setting up new cloud integrations for their S/4 HANA project, there’s usually a clear focus on deadlines, functionality, and a successful go-live.
But how should they operate the integration after go-live? They will have to live with the content for the next 10 years. What kind of documentation will they get with the system?
The post-go-live blind spot
Many integration projects are delivered by external consultancies or system integrators who focus on building and deploying the solution. After the project goes live, these consultants often move on to new clients or assignments.
There is no real KPI around this because what is a well-documented system? In my first XI 3.0 project 20 years ago, we created some Word documents of the integration and dumped them in SOLMAN. They would never be seen and updated.
Sometimes there was a functional specification but it had less than 30% of the detailed logic required for building the interface. Some notes were moved to a Technical Specification, but not everything and hopefully some extra documentation was written about it.
If you have to support such a scenario, you have a real problem. Why is a certain mapping running the way it does?
Test cases have rarely been a part of the delivery, and if they were, they were probably just as outdated as the documentation.
Why it happens
Consultants are often incentivized to deliver on time and within budget. Documentation is usually a last-minute deliverable, created manually and often only at the end of the project. Even if it is provided, it rarely stays updated as changes are made during hyper-care or afterward.
The key questions customers should ask
To protect themselves, SAP customers should ask integration partners upfront:
- How will you document each integration and ensure it remains current?
- What test cases will be included, and how can they be reused?
- Will we have change history?
- Will we be able to see transport history?
- How can we ensure the operational team has what they need to support the system?
If these questions are met with vague answers or promises of “Word docs at the end,” it’s a red flag.
A better approach: automation and traceability
The only way to reliably ensure up-to-date, accurate documentation is to automate it as part of the development and transport process. This is where tools like the Figaf DevOps Suite for SAP Integration Suite stand out.
With Figaf, you can:
- Automatically generate and update interface documentation.
- Track changes to iFlows and configurations with full version history.
- Maintain test cases and run regression tests as part of transports.
- Provide full visibility into transport logs and deployment status.
This ensures that the system your consultants build is one your internal team can manage, support, and improve, without needing to call in favors or dig through old emails.
Final thoughts
Integration is not just about getting data from A to B. It’s about building sustainable, maintainable systems that serve your business for years to come. Documentation, testing, and change tracking aren’t optional, they’re the foundation for long-term success.
As you plan your next SAP integration project, don’t just ask how it will be built. Ask how it will be documented, supported, and evolved after go-live. That’s what separates a quick win from a lasting solution.
