The hardest part of a Forms migration is not the code. It is knowing what the code actually does. Solve that, and the rest follows.
The story you hear from every stalled migration. Ask anyone who has attempted an Oracle Forms migration and watched it stall, and you tend to hear the same story. The analysis phase — working out what the system does, which parts are used, what the business logic actually means — consumed more time and budget than the development itself. There were months of analyst work. There were meetings where business users could not say what they needed, because they had clicked the same screens for fifteen years and the knowledge had become muscle memory rather than something anyone could put into words. There were modules discovered mid-project that nobody knew existed, and blocks of code that looked alive but were not. The development, when it finally began, was rarely the hard part. Understanding what to develop was.
The common thread in failed migrations is that the scope was never properly defined before development began. Traditional analysis relies on people: analysts interview users, who describe what they think they use rather than what they actually use, and the resulting specification document becomes the source of truth even though it is incomplete and already out of date.
Months later, the gaps surface as a project that has committed budget to the wrong scope. The pattern is familiar to anyone who has lived through it — a module nobody mentioned appears in month four, a screen everyone called critical turns out to be unused, a block of code that looks live is, on inspection, dead. None of this is visible from interviews, because it is not what people remember. It is only what the system does.
Getting scope wrong is not a minor setback; it is the mechanism by which migrations overrun, slip and occasionally collapse. A scope built on memory under-counts the work, so the estimate is wrong, so the budget is wrong, so the timeline is wrong — and each correction erodes the confidence of the people who approved the project. This is also why estimates produced in a pre-sales conversation deserve scepticism: an estimate offered before anyone has examined the system is, by definition, a guess dressed as a number. The cost of that guess is paid later, by the team delivering against it and by the executive who staked credibility on it.
A more reliable approach builds the analysis from the system itself rather than from anyone’s recollection of it. It ingests the FMB source files, the database schema, the existing documentation, historical support tickets and test cases — and adds an automated agent that explores the live application and maps how it is genuinely used.
The lack of documentation that is the norm in legacy Forms environments, rather than the exception, stops being a blocker, because the evidence is drawn from what the system contains and does. The question shifts from “what do people remember about this system?” to “what is actually in it?” — and only the second question has a reliable answer.
The automated exploration matters most where memory fails. An agent running against the live system can follow every screen, trace which code paths actually execute, and record the real navigation patterns — the things no user thinks to mention because they happen below conscious attention. Combined with the source files and the database schema, this produces a picture of the system as it genuinely is, rather than as it was documented to be a decade ago or as people half-remember it today.
The output is not a narrative document; it is a set of concrete deliverables.
All of it is produced in days rather than months because the system does most of the talking.
Crucially, the specification belongs to you. Whether or not you proceed with any particular partner for the development, you leave with a clear map of how your system actually functions — documentation of something that, until now, may have lived only in the heads of people who have since moved on. This has standalone value: for the first time, the knowledge is written down and owned by the organisation rather than by individuals.
For regulated environments it has a second value, as audit-ready documentation of a system that previously had none, produced under appropriate information-security controls. And it changes the negotiation that follows, because you are no longer asking a vendor to estimate a system neither of you understands.
That last point quietly shifts the balance of the engagement. Without an independent scope, you depend on the vendor’s estimate and the vendor’s view of the work, with no way to check either. With one, you can compare proposals on equal terms, hold a delivery partner to a scope you both agreed in advance, and walk away from the development entirely while keeping the understanding you paid for.
The analysis is not only clarity; it is leverage in every conversation that follows.
A good analysis is not an end in itself; it is the thing that makes everything after it safer. The precise scope feeds a phased migration plan. The risk register indicates where a proof of concept should start — usually the hardest module — on the principle that if the most difficult screen can be migrated cleanly, the rest follows.
The dependency map enables parallel execution, so the old and new systems coexist on the same database while modules move across one at a time. This is the concrete reason behind the advice to start with the diagnosis: not because analysis is a nice-to-have, but because it is what converts a risky project into a controlled one. Next step. You do not need to commit a development budget to get this clarity. The analysis stands on its own, and it is the cheapest way to take the risk out of the decision that follows.
