How do I replace legacy software without losing the business rules?

Write the business rules down before you replace anything. Gather them from the people who use the system every day, from the structure of its data, and from the reports and documents it produces. Then decide, rule by rule, which to keep, change or drop, and test the new system against the rules you kept.

Old systems often hold rules nobody remembers choosing. They were added over years, and the people who asked for them may have moved on.

Where do the rules hide?

• In the code, as checks, calculations and special cases.
• In the data structure: which fields are required, which records link to which, what values are allowed.
• In the workarounds people use when the system doesn't fit.
• In the reports, whose totals and filters encode decisions about what counts.
• In people's heads: "we never ship to that region on Fridays."

How do I get them out?

Ask the people who use it, each about their own part, privately. Ask what they do when something doesn't fit, not just the normal flow. Look at the database structure; it shows the records and relationships the business relies on, even when nobody can explain them. Compare what people say with what the system does, and note where they differ.

Should I copy every rule into the new system?

No. Replacement is a chance to drop rules that no longer make sense. But it should be a decision, made by someone with authority, and recorded with the reason. Losing a rule by accident is how a replacement breaks something nobody noticed until month-end.

How do I know the new system follows the rules?

Write each rule as a testable requirement with acceptance criteria. Then test the new system with real cases, including the odd ones, and where you can, run old and new side by side on the same data and compare the results.

What else needs planning?

The data you'll move and how it maps, the systems that connect to the old one, what happens to history, and who owns the new system after it goes live. Each of these is easier decided before the build than during it.

What's the most common mistake?

Specifying the replacement from the old system's screens. Screens show what people click, not why. Start from the work and the rules.

Mochlion can read an existing database's structure (not its data) and ask your experts about the rules behind it; see what happens after you buy a credit.