Business Analysis · Requirements
Discovery for an Enterprise Survey Platform Migration
Inventory, stakeholder outreach, and a consolidated requirements list — the discovery work that determines what a replacement platform has to do.
- Requirements Gathering
- Stakeholder Analysis
- Inventory & Retention
- Process Documentation
Overview
A funded enterprise project is replacing an aging survey platform hosting both internal and public-facing forms. Before any platform can be chosen, someone has to answer three questions: what's actually on there, who owns it, and what each line of business genuinely needs.
I lead the day-to-day discovery work — inventory, outreach, requirements gathering, and documentation — working with a manager sponsoring the project and a business analyst supporting the team. Platform selection and architecture assessment sit with others and haven't started; my work is what those decisions will be based on. Unlike my reporting work, the requirements documentation here is mine: I gather it, structure it, confirm it back with stakeholders, and consolidate it.
What I did
Built the inventory
Released- The work
- I compiled a complete inventory of every survey on the platform — 188 in total, spread across the organization — capturing each one's owner, creation date, status, permissions, last response activity, and lifetime response volume. No structured view of the estate existed before this, and the spreadsheet became the foundation for every conversation that followed.
Ran outreach line of business by line of business
Released- The approach
- Rather than sending one generic request, I sent each team a tailored view of their own surveys with core details pre-filled and specific columns for them to complete — whether historical response data needed retaining, whether a form was internal or customer-facing, and how structurally complex it was.
- Why it worked
- Framing it as “here is your list, please confirm” rather than “please tell us what you have” is why I got responses. Teams corrected my data, added forms I didn't have, and updated statuses — which improved the inventory as a side effect.
Gathered and consolidated requirements
Released- Two routes
- Teams with substantial or complex form estates got a meeting, with requirements captured and sent back in writing for confirmation. Teams with lighter usage got a structured written request asking what they rely on, what would be disruptive to lose, and what concerns them about migrating. Both ended in the same place: a documented, confirmed list rather than a recollection of a conversation.
- Handoff
- Requirements from every line of business went into a single consolidated list, and I wrote the context document that lets the next person pick this up — status, stakeholders, what's done, what's outstanding, and which deadlines are time-sensitive.
What discovery surfaced
- A substantial share of the estate was already archived, so a meaningful part of the project is cleanup rather than migration — which changes the size of the problem.
- Survey ownership was heavily concentrated. A small number of creators account for most of the estate, while a long tail of forms have owners who barely use the platform. That determines who actually needs to be consulted.
- Some public-facing forms carry very high lifetime submission volumes and are in active customer use. These aren't surveys — they're operational intake, and migrating them is a materially different exercise from migrating an internal feedback form.
The finding that matters
Requirements gathering surfaced materially different needs between teams. Groups running simple internal forms wanted straightforward things: scheduled open and close dates, results in Excel, ranked selection questions, conditional logic, a confirmation email to the respondent. Groups operating high-volume public intake processes needed considerably more — extensive form customization, branded styling, bulk export, and continuity guarantees for forms customers already use.
That gap is the finding. A platform satisfying the simpler requirements could fail the complex ones, which raises the real question ahead of the project: whether one replacement can serve the full range of use cases, or whether the estate should be treated as more than one problem. Documenting the distance between those positions accurately, rather than flattening them into a single neutral list, is what makes the eventual decision an informed one.
Two populations under one word
One “survey” estate
Internal forms
simple · occasional
- Scheduling
- Excel export
- Ranked questions
- Conditional logic
- Confirmation emails
Operational intake
high-volume · customer-facing
- Extensive customization
- Branded styling
- Bulk export
- URL continuity
- Data-residency rules
May not be one migration problem
Outcomes
- A complete, structured inventory of 188 surveys where none existed before, usable for both migration planning and cleanup
- Confirmed requirements captured from every responsive line of business and consolidated into a single list
- Clear identification of which forms are high-volume, customer-facing, and require the most careful migration planning
- Handoff documentation covering status, ownership, outstanding tasks, and time-sensitive deadlines
What I learned
- Send people their own data, not a blank form. Response rates went up sharply when stakeholders were asked to confirm and correct a list rather than build one from memory.
- Where stakeholders want incompatible things, that difference is worth documenting carefully rather than resolving too early. It was the most useful thing to come out of the requirements work.
- Knowing how much of the estate is dormant, and which handful of forms carry most of the real traffic, changes what the project is actually about.