Inheriting an OutSystems estate you did not build.

1What you are actually holding

Before any opinion about quality, get the inventory. Most of this is an afternoon in LifeTime and Service Center.

• Applications and modules, and which are actually referenced. The gap between what exists and what is reachable is usually large. Anything with no inbound references and no deployment in a year is either dead or a landmine.
• Environment topology. How many environments, and whether there is a real pipeline. Ask whether anyone has ever deployed straight to production, and watch the pause before the answer.
• Extensions. For every C# extension, do you have the Integration Studio source, or only the compiled artefact. Missing extension source is the most common thing that turns a routine change into a rebuild, and it stays invisible until the day you need it.
• Forge components in use, with versions. Note anything unmaintained or several major versions behind. Forge dependencies are inherited debt that nobody chose.
• Integrations, consumed and exposed. Where the credentials live matters more than the count. Site properties, hardcoded, a vault, or some of each.
• Licensing against entitlement. Application object consumption versus what is actually paid for. This is a budget conversation that tends to arrive uninvited.

2The tells

These predict pain rather than describe it.

• Layering violations. Upward references, core modules calling end user modules, cyclic dependencies. A pass in Discovery gives you this faster than reading code.
• Fan-in concentration. Which modules everything depends on. High fan-in is not bad in itself, but it tells you where a small change becomes a full regression.
• God modules. Anything carrying a few hundred screens or actions was never refactored, and will not be without a reason.
• Logic in screen actions. Business rules living in the UI layer rather than in server actions is the clearest sign the estate grew under delivery pressure.
• Aggregates versus SQL widgets. Heavy raw SQL usually means either a performance workaround or a modelling problem. Worth knowing which.
• Timers and async work. Whether long running jobs are idempotent and restartable. Ask what happens if a timer dies halfway. If nobody knows, that is the answer.
• Session state. Session variables carrying application state rather than user context is a scaling ceiling nobody notices until it matters.
• Security enforcement. Roles defined is not roles enforced. Check that server actions themselves check, not only the screens in front of them.

3Data and performance

• Aggregates filtering on unindexed columns, and the entity growth curve sitting behind them.
• Aggregates inside loops. The N+1 pattern is as common here as anywhere else.
• Entities with unbounded growth and no archival strategy.
• Binaries stored in entities rather than object storage.
• The slow query list in Service Center, and whether anyone has ever opened it.

4Operational reality

• Error log volume, and more importantly whether anyone reads it. An unread log is the same as no log.
• Deployment frequency, and whether a rollback has ever actually been performed rather than merely documented.
• Whether any automated tests exist. Usually not, which is fine to know rather than discover.
• Platform version currency and end of support dates.

5ODC readiness

Worth separating, because ODC is a different runtime rather than an upgrade. The assessment is about what ports, not about what works today.

The question to answer is what proportion of the estate is portable logic versus platform coupled.

• C# extensions do not carry over. They become external logic, which is a different integration and a different operational model. Count them early, because they usually set the timeline.
• On premise data access needs a private gateway, and the network conversation is often slower than the technical one.
• BPT processes have no direct equivalent. Anything modelled as a long running process needs rethinking rather than porting.
• The reference architecture differs. Core and foundation module conventions do not map cleanly onto libraries.
• Forge dependencies may simply not exist on the other side.

The practical recommendation is to take one bounded, low blast radius application end to end as a migration probe, rather than assessing the whole estate on paper. A probe gives you a real multiplier for everything else. Paper estimates for this consistently come in low.

6If agents are on the roadmap

An estate becomes agent ready in roughly the order below, and most of it is ordinary good practice rather than anything AI specific.

• Clean, documented, permissioned APIs. An agent can only act through what has already been exposed deliberately.
• Business data in well modelled entities rather than implied by screen flow.
• An audit and event history worth reading. Estates that already record who did what and when are far ahead, and it is usually the operational apps rather than the customer facing ones.
• An identity and permission model that can be safely delegated. This is the part most people reach last and should reach first.

7Sequence

• Weeks 1 to 2. Access to everything, then inventory. Do not form opinions yet.
• Weeks 3 to 4. The tells in section 2. This is where the shape of the estate becomes obvious.
• Month 2. A written risk register ordered by what would hurt most if it happened next week, plus two or three visible quick wins to buy credibility.
• Month 3. Roadmap, and the ODC probe if that is the direction.

8The questions that are not technical

Ask these of people, and weigh the answers above anything in the code.

• Who was the last person to deploy each application, and are they still here.
• What breaks most often, and what is the workaround everyone already knows.
• Which application will nobody touch, and why.
• What does the business think the platform is for, and how far is that from what it actually does.
• Who asks for changes, and who is allowed to say no.