Walls can look straightforward when viewed only as an application. In practice, its value is the security it enforces across connected systems. That changes how an upgrade should be planned and tested.
Document the Walls web/application components, database, supporting services and the extensions or integrations that apply security to downstream systems. The exact components vary by environment and release, so confirm them against the current vendor requirements.
Review the target release requirements for Windows, .NET, SQL Server, IIS and any supporting services. Do the same for each connected extension. A prerequisite discovered during the production window is avoidable risk.
The database matters, but so do application configuration, IIS settings and integration configuration. Record service identities and relevant scheduled or integration processes as part of the recovery position.
After the upgrade, create representative scenarios and confirm that walls are applied and removed correctly in connected systems. Test the systems users actually work in, not only Central Administration.
DMS, finance and other extensions deserve their own validation. If a connected system has also changed version, avoid assuming compatibility from a successful login. Use the current vendor compatibility information for the exact combination you intend to run.
Sources were reviewed on 22 August 2026. Product and release guidance changes; always verify the current Intapp documentation before production work.
Pinnacle IT Consultancy Limited is an independent consultancy and is not affiliated with or endorsed by Intapp. Product names and trademarks belong to their respective owners. This is general technical commentary, not a substitute for current Intapp documentation, release notes, compatibility guidance or an assessment of your environment.
Share a lesson, challenge or question. Submissions are moderated and never published automatically.
