Compare approaches
PYD ENTERPRISES vs. rewriting from scratch
A from-scratch rewrite designs the new system from interviews, documents and current business requirements, treating the old code as a black box. PYD ENTERPRISES keeps the rewrite and removes the black box, so the new design starts from what the old system actually does.
THE SHORT VERSION
Rewrite the system, not the knowledge. A rewrite that starts from an extracted specification keeps every advantage of a clean design and drops the risk of rediscovering thirty years of edge cases in production.
Side by side
Rewrite from scratch vs. PYD ENTERPRISES
| Dimension | Rewrite from scratch | PYD ENTERPRISES |
|---|---|---|
| Starting point | Interviews, process maps, existing documents | Extracted rules, contracts and lineage, then interviews |
| Hidden rules | Found in UAT, parallel run or production | Found before design, with source references |
| Design freedom | Complete | Complete: the spec describes behavior, not structure |
| Equivalence testing | Hand-built from what testers know | Generated fixtures at every branch boundary |
| Decision on obsolete rules | Implicit: forgotten rules simply disappear | Explicit: each rule is kept, changed or retired by a reviewer |
| Upfront cost | None for discovery | $25,000 per system or $85,000/year portfolio |
The appeal of a clean start
Rewriting from requirements is attractive for good reasons. The business has changed since the system was built, the old code is full of workarounds, and nobody wants to carry decades of accidental complexity into a new platform. Product owners can describe what they need today; engineers can design for it with modern patterns; nobody has to read COBOL.
Where rewrites go wrong
The risk sits in the rules nobody mentions in a workshop because nobody remembers them: a rounding step added for one state regulator, a fee waiver for accounts opened before a merger, a holiday calendar exception in the ACH cutoff. These rules are in the code because someone needed them once, and some of them still matter. In a rewrite they surface late, as reconciliation breaks in parallel run or as customer complaints after cutover, when they are most expensive to fix. The TSB migration in 2018, which led to a combined £48.65M FCA and PRA fine in December 2022, is a public reminder that cutover failures carry regulatory as well as operational cost.
The opposite failure also happens: a rewrite team, unsure what the old system does, rebuilds everything defensively, including rules that were retired years ago.
A rewrite that starts from the specification
PYD ENTERPRISES does not change the decision to rewrite; it changes the starting material. Before design begins, every business rule in the old system is extracted into a DMN table or a calculation spec with a source reference, and every interface into an OpenAPI or AsyncAPI contract. Product owners and SMEs then go through the inventory and mark each rule keep, change or retire. The new design is free to look nothing like the old one, and the generated equivalence fixtures cover exactly the rules marked keep.
Fair is fair
When rewrite from scratch is the right call.
We would rather lose a deal than sell PYD ENTERPRISES where it does not fit.
- The business process itself is being replaced, so the old system's rules are largely irrelevant to the new one.
- You are moving to a commercial package (a SaaS core, a rating platform) and will configure it from current requirements, accepting a gap analysis rather than a full rule inventory.
- The legacy system is small and well understood by a team that is still in place.
- Regulation or product strategy has changed so much that equivalence with the old behavior is not a goal.
FAQ
Common questions.
Doesn't extracting the old rules just recreate the old system?
Only if you keep every rule. The inventory is a decision list: reviewers mark each rule keep, change or retire, so the new system carries forward only what the business still wants.
We are buying a package. Is PYD ENTERPRISES still useful?
Often, yes. The rule inventory becomes the gap analysis: which legacy rules the package covers in configuration, which need extension, and which can be retired.
How early should the scan run?
Before design and before the build estimate. Most teams run it in the first two to three weeks of a program.
Other comparisons
- PYD ENTERPRISES vs. manual code auditUse people for judgment and tools for enumeration.
- PYD ENTERPRISES vs. generic llm migrationUse language models to describe rules, not to find them.
- PYD ENTERPRISES vs. automated transpilersTranspilation moves the code; specification extraction moves the knowledge.
- PYD ENTERPRISES vs. lift-and-shift rehostingRehosting changes where the code runs; it does not change what you know about it.
Compare on your own code.
Run PYD ENTERPRISES on up to 100,000 lines for 14 days in your VPC and put the output next to whatever you use today.