“How long will it take?” is the first question any Forms migration faces, and it usually gets one of two unhelpful answers. Either a vague range so wide it means nothing, or a confident figure that is really a guess dressed up as a commitment. Neither helps anyone plan. The useful answer is different in kind: it names the things the timeline actually depends on, most of which can be known before the project starts.
As a baseline, a system with roughly twenty to thirty actively used modules typically migrates in something like three to six months. That is a starting reference, not a promise — every system is different — but it anchors expectations in the right order of magnitude. The headline worth holding onto is that a well-run Forms migration is measured in months, not years. Projects that stretch into multi-year efforts have usually gone wrong somewhere, most often in scoping, rather than being inherently that large.
The range exists because systems differ enormously beneath a similar surface. A focused application with a dozen genuinely active modules can be migrated in a couple of months; a sprawling estate with sixty modules, deep integrations and heavy power-user workflows is a longer effort — though often less long than the total module count suggests, once the dead and rarely used screens are stripped out. The headline figure matters less than knowing which end of the range your system sits at, and that is a question the analysis answers precisely rather than leaving to a rule of thumb.
What drives the timeline is a short, specific list. The number of actively used modules matters far more than the total, because many modules in an old system are dead and need only to be retired. The complexity and screen density of the live modules matters, since a dense, logic-heavy screen takes longer than a simple one. The chosen path matters: keeping the database is faster than migrating it. Data volume and quality play a part. And the availability of your own team to validate and sign off each module is often the quiet bottleneck. These are the real variables, and none of them are mysterious.
| Factor | Effect on the timeline |
|---|---|
| Actively used modules | More live modules lengthen it; dead modules do not count |
| Module complexity & density | Complex, high-density screens take longer |
| Chosen path | Keeping the database (APEX, modern front end) is faster than a full exit |
| Database migration | Moving the database to PostgreSQL adds the most time |
| Team availability | Limited availability for validation slows sign-off |
| Power-user UX needs | Preserving dense, keyboard-driven workflows adds design effort |
There is also a subtlety in what done means. With phased, parallel migration, modules go live progressively rather than all at the end, so value and risk reduction begin arriving long before the project formally finishes. For planning purposes, the more useful figure is often not total duration but time to the first module in production — which can be weeks. A migration that delivers continuously is easier to fund and to justify than one that asks for months of investment before anything works.
The reason pre-sales estimates are unreliable is the same reason migrations overrun: a number offered before anyone has examined the system is a guess, and the single biggest threat to any timeline is discovering scope mid-project. An evidence-based diagnosis removes that threat by establishing the real scope, the dependency map and the risks up front — in days, with estimate accuracy in the region of ninety percent. The timeline it produces is a plan grounded in what is actually there, not an aspiration that the first surprise will overturn.
The cost of getting this wrong is not only the extra weeks. A timeline that slips repeatedly erodes the credibility of the people who set it, drains the goodwill the project needs to finish, and can push a migration past the support deadline it was meant to beat. A realistic schedule that holds is therefore worth more than an optimistic one that does not, even if the realistic figure is larger. Part of the value of the analysis is that the date it produces is one the business can actually plan and commit around, rather than one it will have to walk back.
Getting a timeline you can actually plan around follows a simple order. Commission the analysis first. Use it to fix the scope, map the dependencies and surface the risks. Sequence the modules into phases, with the hardest or highest-value first. Only then is the timeline a schedule rather than a hope — and only then can the business make commitments around it with any confidence. The few days the analysis takes are repaid many times over in a date that holds.
Next step. A diagnosis turns “how long?” into a sequenced, evidence-based schedule, with a realistic date you can plan around.
