Due Diligence

The Year 2 Problem: What It Is and Why Institutional Investors Should Care

Due diligence platforms often stop scaling as questionnaires evolve and programs grow. The root cause is data architecture.

Dasseti
May 28, 2026
Updated: Jun 2, 2026
Due Diligence

Subscribe

Subscribe

Most due diligence platforms deliver exactly what teams expect in Year 1. The problems tend to surface later, when the team moves a question on a DDQ, adds a new field, or launches an ad-hoc request. Reports stop producing reliable output, dashboards go blank, and integrations return errors. We call this the Year 2 Problem.

It's a pattern we've seen repeatedly with allocator teams who moved to Dasseti after running into the limits of their original platform, and it rarely shows up at the point of selection. Platform selection generally focusses on digitizing workflows and bringing the due diligence process into one central platform, and most software handles that well. The data architecture underneath only gets tested later, when reporting, analytics, and integration needs start to outgrow the original implementation.

Why the Year 2 Problem happens: questionnaire-centric vs profile-centric architecture

The Year 2 Problem traces back to one foundation-level product design decision: how the platform stores collected data.

The questionnaire-centric model

A questionnaire-centric platform ties data to the questionaire it was collected on. To retrieve any data point, the system needs four references: Manager, Questionnaire ID, Question ID, and Version. Those references work as long as none of them change. The moment any of them do change, the link between historical and current data has to be reconstructed manually.

The profile-centric model

A profile-centric platform treats the questionnaire as a way to collect data, not the place where data lives. As responses come in, the platform extracts them, normalizes them, and stores them in a central manager or fund profile. Analytics pull from the profile using two references: Manager and Field Name. Those don't change when a questionnaire changes. You can rebuild a DDQ from scratch and the underlying data set stays intact, queryable, and comparable across years.

Both models look almost the same in Year 1, when all that's being tested is whether the platform can digitize a questionnaire. They split sharply the moment the data needs to do anything beyond living inside a completed questionnaire.

We go into this in more detail in our recent webinar, which you can watch on demand here.

What triggers The Year 2 Problem

The name is a heuristic, not a deadline. The pattern can show up in month nine for a team running a fast-moving program, and it can take three years to surface for a team whose templates and analytics expectations stay flat. What defines The Year 2 Problem isn't when it hits, but what triggers it.

Moving or renaming a question

On a questionnaire-centric platform, every historical data point is tied to a specific question ID inside a specific questionnaire version. Renaming or relocating a question changes the reference. Historical analytics that pointed at the old reference no longer find the data. The information has not gone anywhere; the platform just no longer knows how to retrieve it consistently.

Adding a new field or questionnaire

When a regulator, investment committee, or a portfolio event creates a new data requirement, a questionnaire-centric platform stores the new data point inside the new questionnaire instance. It does not join the existing data set in any structured way. The team has not gained a new field they can analyze across managers; they have gained a new silo that has to be tracked separately.

Launching an ad-hoc request

ESG incidents, geopolitical exposure, a critical event affecting a single manager. The ad-hoc questionnaire goes out, responses come back, and the data lives inside that ad-hoc instance. It doesn't flow into the manager profile, doesn't roll up next to the annual DDQ, and can't be queried against the rest of the program without manual mapping.

None of these are edge cases. They are the operational reality of any due diligence program that evolves with its market. 

How The Year 2 Problem affects due diligence teams

For teams running into the Year 2 Problem, the impact usually shows up in four places.

Reports stop being trusted

The team either rebuilds reports manually each cycle or quietly stops using them and runs analysis in spreadsheets instead. You're still paying for the platform, but a lot of the analysis is happening somewhere else.

Integrations stall

Connections to risk systems, CRMs, BI tools, and external data providers require version-by-version remapping every time a template is refreshed. What was sold as straight-through processing becomes a perpetual mapping project owned by IT.

Multi-year analytics take hours of manual work to produce

Multi-year trend analysis is one of the most valuable outputs of a long-running due diligence program. On a questionnaire-centric platform, producing it usually means reconciling each year's data against the version it was collected on, a manual job that can take hours or days. The data is there, but pulling it together consistently is time-consuming work and often ends up happening in spreadsheets rather than the platform itself.

Migration becomes the only fix

The Year 2 Problem can't be fixed inside the platform that created it. The data model is set at the platform level, and changing it means changing platforms, with all the implementation, training, and historical data conversion that involves.

How AI extends The Year 2 Problem

AI is where the Year 2 Problem now compounds fastest. The output a model produces is only as reliable as the data structure it works on. When AI sits on top of a questionnaire-centric platform, it inherits the fragmentation. Ask it for a multi-manager comparison and it has to reconcile data scattered across hundreds of questionnaire instances, with no shared schema and no normalized field reference. The model produces something, but no one can trust it without manually checking the source data.

AI-native platforms that skip structured collection entirely produce a different version of the same problem. Applying AI to fragmented inputs doesn't solve the issue; it accelerates it. Every AI conversation becomes its own data silo, and the team ends up with hundreds of micro-silos instead of one queryable foundation.

AI works for due diligence when it sits on top of structured, profile-level data. Without that foundation, it scales the existing fragmentation rather than resolving it.

Why allocators should care now

The demands on due diligence teams are growing in every direction: more managers, more frameworks, more pressure to integrate due diligence data with the rest of the investment operations stack, and a growing expectation that AI will do something useful with all of it.

A questionnaire-centric platform can absorb some of that growth in Year 1 and still feel like progress, but it can't absorb it indefinitely. The cost of selecting on workflow rather than architecture surfaces two, three, or five years later, when the team needs their data to do more than sit inside completed forms. By then, the workarounds have become part of how the team operates, and the only way forward is the one the team thought they'd already taken: moving to a platform built around a stable data layer.

Every due diligence platform can digitize a DDQ. The question worth asking, before selection and continuously after, is whether the data underneath the platform is built to last as long as the program is.

If you're evaluating a new platform or pressure-testing your current one, we've put together five direct questions that reliably surface what's in the data layer: 5 Questions to Ask Your Due Diligence Platform Provider.

 

Similar posts

Get notified about new investment sector insights

Stay up to date with the latest insights from the Dasseti team.

 

Sign up for blog alerts