Why You Still Need a Human to Sign Off on That Enterprise Migration RFP

Every pre-sales team has run this experiment by now: dump the RFP PDF and your content library into an LLM, hit generate, and see what comes out. For a small, well-scoped engagement, the draft might actually be decent. For a large-scale enterprise application modernization — a legacy .NET or Java estate moving to Azure, a data platform replatforming onto AWS, or a multi-year application portfolio overhaul,  the draft will read beautifully and still be wrong in ways that matter.

The failure mode isn’t bad grammar. It’s confident, well-formatted text that quietly skips the two things enterprise buyers actually scrutinize: do you understand our system, and do your numbers make sense.

The two things AI drafts fake instead of solving

Old-school enterprise RFPs had two load-bearing sections that separated a serious vendor from a template-shop: a requirement understanding writeup (usually anchored by a high-level architecture diagram) and a time-and-cost breakdown built off a work breakdown structure (WBS).

Both of these are supposed to be evidence that you’ve actually thought about this system, not a generic one.

Requirement understanding and architecture. For an enterprise migration RFP, the architecture section needs to reflect specifics: is this an on-prem monolith moving to Azure App Service and AKS, or a set of tightly coupled services being re-platformed onto AWS ECS or Lambda? Is there a shared database that needs to be decomposed, or scheduled batch jobs, message queues, and vendor-specific integrations (an ESB, a mainframe connector, a legacy identity provider) that don’t have a clean cloud-native equivalent? Is the target environment a straight rehost, a replatform, or a full refactor — and does the RFP even distinguish between those, or does it assume all three cost the same?

An LLM can produce a very plausible-looking architecture diagram and narrative for “legacy application to cloud-native on Azure/AWS.” It has seen thousands of those. What it can’t do is know whether your target architecture is honest about this client’s constraints — their security posture, their existing CI/CD maturity, whether their data residency rules rule out the region you’re assuming, whether their ops team can actually run a Kubernetes-based platform or whether that’s aspirational. It will fill those gaps with the most common pattern in its training data, not the correct one for the deal in front of you.

Time and cost, built on a WBS. This is where AI-only drafting gets genuinely dangerous, because the numbers look precise even when they’re fiction.

A real WBS-based estimate for something like an Azure or AWS migration depends on variables no model can see:

• The actual skill level and throughput of the engineers who’ll do the work — not a generic “senior cloud engineer” productivity assumption, but how fast your team moves on unfamiliar codebases.
• How much of the migration can be accelerated with AI code-assist tools (transpilers, GitHub Copilot–style refactoring, custom migration scripts) versus how much needs manual rewrite because the legacy code is too tangled or too risky to automate.
• Your developers’ actual comfort level with the target stack. A team fluent in Azure-native services (or AWS-native, depending on the target) and comfortable with an AI pair-programming workflow will move at a different pace than one that’s never touched containers or infrastructure-as-code.
• API and integration surface area — how many external systems, how brittle the contracts are, how much regression testing each cutover needs.
• Technical debt that isn’t visible from the RFP document itself, only from actually looking at the code.

An LLM doesn’t have access to any of that. It doesn’t know your team’s velocity, doesn’t know which of your engineers ships fast with an AI assistant and which one still hand-rolls everything, and has no visibility into how mature your internal tooling is. So it defaults to industry-average benchmarks and generic effort multipliers pulled from whatever proposals or public estimation frameworks it was trained on. The estimate will look rigorous — broken into phases, with percentages and contingency buffers — but it’s benchmarked against nobody in particular. That’s a dangerous kind of wrong, because a wrong number that looks careful gets rubber-stamped faster than one that looks rough.

Where this goes wrong without a human check

Left alone, an AI-drafted response to a complex migration RFP tends to fail in a few predictable ways:

• It commits to a modernization pattern that’s technically standard but doesn’t fit the client’s actual legacy footprint, and nobody catches it until the discovery phase blows past the estimate.
• It quietly assumes greenfield-level velocity for what is actually a brownfield migration full of undocumented dependencies.
• It treats “we’ll use AI tooling to accelerate the migration” as a blanket productivity multiplier, without checking whether the client’s codebase is even in a state where automated refactoring and code-conversion tools are reliable — some legacy applications are too irregular for that to work cleanly.
• It skips over scope that’s implied but not stated outright: data migration validation, parallel-run testing, rollback planning — the stuff that eats budget on real migrations and is easy for a model to leave out or gloss over.

None of these show up as an obvious error in the document. They show up six months into delivery, as a change order or a missed milestone.

What actually works: AI drafts, a human owns the call

The fix isn’t avoiding AI — it’s being precise about what it’s allowed to decide unsupervised.

1. Let AI do the first pass. Summarizing the RFP, extracting requirements, and pulling a first-draft architecture narrative from your vetted content library is exactly what it’s good at.
2. Route the architecture section through a solution architect. Someone who’s actually seen this client’s stack, or asked the discovery questions needed to know it, has to validate the diagram and the modernization approach before it goes out.
3. Route the WBS and estimate through whoever owns delivery. They know your team’s real velocity, your AI-tooling adoption, and where the legacy code is going to fight back. That knowledge doesn’t exist anywhere in the RFP text, so it can’t come from a model reading the RFP text.
4. Treat every number and every architectural commitment as a “speed bump” item — nothing with a dollar figure, a timeline, or an SLA attached goes out without a named human signing off on it.

The pitch that wins large migration deals isn’t the one with the most polished draft. It’s the one where the architecture and the estimate both hold up when a skeptical buyer’s engineering team starts asking follow-up questions. AI can get you to a strong first draft fast. Getting the final answer right still depends on someone who actually knows your team and your client’s system — and that’s not something a model can benchmark its way into.