How to choose a web app partner who won't break your data governance
A practical RFP checklist for anyone replacing a legacy business application — written for the leaders modernizing master data, not just the ones modernizing screens.
Somewhere in your organization, there is a web application that has quietly run the business for two decades or more. Nobody remembers who wrote the approval logic. Nobody is quite sure why one region's onboarding form has four extra fields. And yet, every day, thousands of transactions flow through it into your ERP — some clean, some not.
Replacing that system is not really a web development project. It's a governance project wearing a web application's clothes. And that distinction is exactly what most RFPs get wrong — which is why so many "successful" builds still leave companies with the same dirty, ungoverned data they started with, just wrapped in a nicer interface.
This checklist is for the people who know the difference. It's built from the questions we ask ourselves before we ever open a code editor — because we're not just building you a web app. We're helping you decide, deliberately, what should be rigid and what should be allowed to bend.
Why most web app RFPs fail before a line of code is written
The uncomfortable truth is that most enterprise software projects don't fail during development. They fail at the requirements stage — long before anyone opens a code editor, and often long before a vendor is even chosen.
For a distributor or customer onboarding platform sitting in front of SAP S/4HANA, this isn't an abstract risk. Every unchecked field, every approval step nobody documented, every "we'll just hardcode it for now" decision becomes a data governance problem the moment it goes live — and a very expensive one to unwind later.
Rigid enough to govern. Flexible enough to evolve.
Every legacy system you're replacing failed the same way: it was built rigid where the business needed flexibility, and flexible (read: unchecked) where the business needed rigor. Distributor codes get created three different ways in three different regions. Credit limits get overridden in a spreadsheet, not the system. Twenty-five years of "just this once" exceptions become the system's actual architecture.
The fix isn't to make the new system maximally flexible — that just recreates the same chaos with a modern UI. And it isn't to make it maximally rigid — that guarantees the business will route around it again within eighteen months. Gartner's framing of composable business architecture is useful here: modularity and autonomy at the edges, with a governed, non-negotiable core underneath. Some research groups project that a majority of new enterprise applications will be built this way by the end of the decade — not because it's fashionable, but because it's the only design pattern that survives contact with a real, changing business.
In practice, this means separating your system into two deliberately different layers:
This is the difference between an application that ages well and one that becomes next year's legacy problem. The core — your master data model, your validation rules, your integration to SAP — stays governed and boring on purpose. The edge — how a workflow routes, what a form looks like in a new market, what threshold triggers an approval — is designed to be reconfigured by a business owner, not re-engineered by a developer.
What to put in your RFP — and what to score vendors on
Seven categories. Ask these before you ask about price. A vendor's answers here tell you far more about how your data will look in three years than any demo will.
Business process & governance discovery
- Do they map your current approval chains and exceptions, not just the screens you want redesigned?
- Have they identified who owns each data domain — customer master, material master, distributor master — before proposing a data model?
- Can they show a RACI for ongoing data stewardship, not just a project Gantt chart?
- Did they ask what happens when a rule changes six months after go-live — not just what happens at launch?
Data architecture & master data governance
- Is master data governed centrally and separately from the transactional workflow logic?
- Is there a staging and validation layer before anything reaches your ERP, so nothing lands unchecked in SAP?
- Is there a clear survivorship and de-duplication rule for when the same distributor or customer shows up twice?
- Are validation rules and mandatory fields stored as configurable data, not hardcoded into the UI?
ERP & SAP compatibility
- Do they default to standard SAP APIs, BAPIs, or OData services instead of writing directly to tables?
- Are integrations designed to be idempotent and safely re-runnable if something fails mid-transaction?
- Is there a defined reconciliation process for when the ERP integration fails part-way through?
- Have they scoped a phased cutover plan that coexists with the legacy system, rather than a risky big-bang switch?
Solution design flexibility
- Can approval chains, thresholds, and routing be reconfigured by a business admin without a code release?
- Is there version control and an audit trail on business rule changes — who changed what, and when?
- Does the architecture clearly separate a governed core from a configurable edge, in writing, before build begins?
- Can the system support a new market or region — different tax rules, languages, compliance — through configuration rather than a rebuild?
Team composition & consulting depth
- Does the proposal include a business process consultant, not only developers and a project manager?
- Has the team worked inside your ERP landscape before — the same modules, not just "SAP experience" on a slide?
- Do the people who ran discovery stay on through design and build, or does context get lost in a handoff?
- Will they push back on scope that undermines governance, or agree to everything to win the deal?
Evaluation & commercial criteria
- Is any part of pricing tied to outcomes — data quality thresholds, adoption — rather than only hours billed?
- What's the ratio of configuration to custom code in the estimate — a fair proxy for how maintainable this will be in year three?
- Is hypercare and post-launch governance support explicitly scoped, or does support quietly end at go-live?
- Can they show a reference architecture diagram before the contract is signed — not just case study logos?
Governance after go-live
- Who owns data quality metrics after launch — the vendor, or a named person inside your organization?
- Is there a defined cadence for reviewing business rules — a quarterly governance council, or similar?
- Does the partner offer a way to benchmark data maturity over time against where you started?
What this looks like on the ground
We're currently working with a consumer goods manufacturer operating across India, the Middle East, and South-East Asia to replace a distributor and customer onboarding platform that had run, largely unchanged, for 25 years. On paper, it looked like a UI refresh. In practice, it's a master data governance project: closing the gaps that let unchecked, manually entered data flow straight into SAP S/4HANA.
The design brief we set for ourselves was the same one in this article — a governed core around master data and SAP integration, with a configurable edge for the onboarding workflows and approval routing that differ by market. It's slower to design up front. It's dramatically cheaper to live with afterward.
Write an RFP that protects your data, not just your timeline
Before you send out a single RFP, we'll walk through your current architecture and flag exactly where it's likely to break — free, no obligation. If it's useful, we'll also show you where a Master Data Maturity Assessment fits into your evaluation process.
Quantyform Tech · Master Data Management, SAP/ERP Consulting & Data Analytics