What to put in a legacy application modernization services RFP

A legacy application modernization services RFP needs eight things to produce comparable bids: a module inventory, an integration list with named owners, data volumes and known quality problems, an explicit rollback requirement, reconciliation criteria agreed with finance, numeric acceptance thresholds, the post-launch support model, and one pricing format that every bidder must complete.

Most modernization RFPs describe the system the buyer wants and say almost nothing about the system they have, which is the only part a bidder cannot research. The result is a set of proposals priced against different assumptions, none of which survive contact with the legacy database. This article sets out what to write instead, section by section, with the thresholds that make a bid enforceable.

Why a modernization RFP is different

A modernization RFP is a request to change a system that is already running and already load-bearing. Nobody is asking for a greenfield build, so the interesting risk is not in the target architecture; it is in the fifteen years of undocumented behaviour, the eleven downstream systems reading the database directly, and the ledger that has never quite balanced since a migration in 2014.

That makes the discovery section the most valuable part of the document. A bidder who understands the constraint will price the unknown honestly and tell you where they cannot commit without access. A bidder who does not will quote a low, confident number and recover the difference through change requests in month four. The hidden costs modernization quotes leave out are almost all consequences of an RFP that did not ask.

It also changes what you are buying. A rewrite is a product purchase; incremental modernization is a sequence of controlled changes to a live system, each with its own go-live and its own reversal path. Your RFP should make clear which one you are asking for, because the two produce incomparable proposals. The distinction is drawn in application modernization versus a rewrite.

The sections, and what to ask for in each

Acceptance criteria with numbers in them

Acceptance criteria written in adjectives cannot be enforced. Every threshold below should carry a figure your own team has agreed, because these are the sentences that decide disputes eight months from now.

• Functional equivalence. The replacement matches the legacy system's outputs on an agreed sample of real transactions, with every difference explained and accepted in writing.
• Reconciliation tolerance. Which totals must match exactly, which may vary, and by how much. Finance signs this, not the project team.
• Rollback time. The maximum minutes to return a function to the legacy path, demonstrated in a rehearsal rather than described in a document.
• Performance. Response time at the busiest hour of your busiest day, measured with production-like volumes, not on an empty database.
• Parallel-running exit. The difference log is closed and understood, rather than the calendar window merely having passed.
• Security. Controls mapped to a published baseline such as the OWASP Top Ten, which sets out the most critical security risks to web applications and gives you a common reference every bidder recognises.
• Documentation and handover. Runbooks, architecture notes and prompts or configuration delivered as a condition of final payment.

How should the RFP ask for pricing?

Ask for a fixed price per phase, with each phase defined by the modules it replaces, and require every bidder to use the same table. Day rates make bids look comparable while hiding the only number that matters, which is total cost to deliver a working module. If you want a genuine range instead of a single figure, ask each bidder to price a low, expected and high scenario against the same module list.

Published starting prices give you an anchor before any bid arrives. A legacy-to-AI modernization programme at Eazyware starts at $31,500 or ₹22,40,000 and runs to $105,000 or ₹72,00,000 and beyond for heavily integrated systems, and a custom replacement through custom enterprise software development starts at $24,500 or ₹16,00,000. Everything published sits on the pricing page. A bid materially under the lower end of that range is not a better deal; it is a different scope, and the RFP should ask which parts were excluded.

Price the support period in the same document. A Care Plan starts at $1,000 or ₹68,000 a month for business-hours cover with an eight-hour response, rises to $2,500 or ₹1,60,000 for 24x5 and a four-hour response, and reaches $5,250 or ₹3,40,000 for 24x7, a one-hour response and a named engineer. Asking for support pricing alongside build pricing prevents the common surprise of a cheap build followed by an expensive dependency.

What should the RFP say about data and the DPDP Act?

Say where personal data may be processed, who may see it during delivery, and what happens to test copies afterwards. Under India's Digital Personal Data Protection Act 2023, the organisation that decides why and how personal data is processed carries the obligations, and that organisation is you, not your supplier. An RFP that stays silent on this hands the question to whoever is cheapest.

Three requirements are worth stating explicitly. Test and migration environments must use masked or synthetic data unless there is a written reason not to. Supplier access must be role based, logged and revoked on a named date rather than at the end of the programme. Any data leaving India, including copies held for debugging, must be identified in the bid rather than discovered in an audit. The broader control set is covered in modernization, security and the DPDP Act.

Clauses that quietly decide the programme

Ownership

State that the client owns the code, the infrastructure definitions, the configuration and the documentation, and that this survives termination. We work this way as standard, and any bidder unwilling to put it in writing is telling you something useful before you sign.

Exit and handover

Define what handover means in artefacts: a running environment reproducible from source, a runbook, an access list and a knowledge transfer session per module. Handover that is a meeting rather than a deliverable is not handover.

Change control

Agree in advance how a new requirement is priced and who approves it. Without this, scope arrives informally through a friendly email in week nine and the fixed price stops being fixed. Fixed scope, fixed date and fixed price only hold together when the third one is defended.

Access during the bid

Decide what bidders may see before pricing: read-only database access under NDA, an anonymised data extract, or nothing. The more you allow, the more accurate the bids, and we sign NDAs before the first working session for exactly this reason.

What to leave out

Three things make a modernization RFP worse. Specifying the target technology stack in detail narrows your bidder pool for no gain, since the constraint that matters is your existing integrations rather than a framework preference. Demanding a fixed end date for the whole programme before discovery forces every honest bidder to pad and rewards the one who does not. Asking for a free proof of concept transfers your risk to bidders who will price it back into the build or decline to bid at all.

If the requirement is genuinely unclear, a short paid discovery engagement is the cleaner instrument. A fixed-price discovery sprint at $3,250 or ₹2,00,000, credited against the build, produces the inventory the RFP was missing, and you can then run a tighter bid with everyone pricing the same reality.

How to score the responses

Weight the current-state and rollback sections most heavily. Any competent supplier can describe a target architecture; far fewer can tell you precisely how they will find undocumented behaviour, how long a reversal takes, and what happens if finance disputes a total. Score for specificity: a named method, a named duration, a named person. Our own reference for this is the university ERP modernization case study, where the sequencing was set by the academic calendar rather than the delivery plan.

Related reading

Questions to ask a modernization vendor before you sign covers the conversation after the paperwork, a practical implementation guide shows the delivery shape a good bid should describe, and how to compare proposals when nobody quotes hourly helps with scoring. If you would like a draft scope reviewed before it goes out, our team will read it through the contact page.

An RFP that describes the system you have, rather than the one you want, is the only kind that produces quotes still standing in month six.