PMaker home
Accept the old world first, then put new value behind a controllable boundaryLegacy systemMainframes, shared drives, private APIsIt will not move for youFDERead old · write newNew workflowInterfaces, evals, gradual replacementValue starts running Be compatible in data, independent in architecture, and respectful of user habits

Read from the old world, keep the new boundary under control, and follow human habits.

Read Old, Write New

Keep data compatible with legacy systems while keeping the new architecture independent and controllable.

The customer’s old system may be a twenty-year-old mainframe, a department tool, or a hard compliance boundary. During MVD, how much should a new solution accommodate it? The answer is a middle path: read old, write new.

After reading, you should be able to answer:

  • Why is a new system beside the old one safer than a rewrite?
  • How can value run without touching the core legacy system?
  • How can the new workflow gradually replace the old one instead of forcing a hard cutover?

In data: deep compatibility

Read the data where it already lives: mainframes, shared spreadsheets, and private interfaces. Data is a precondition for proving value and will not move just to suit your architecture. Even systems with no API can sometimes be bridged through controlled browser automation, reducing the cost of the first integration.

In architecture: do not become a parasite

Keep the validation system inside a boundary you control and connect to the old system through interfaces. Half of an early solution may be rewritten; changes inside the old system can take months; and a reversible boundary gives both sides room to negotiate.

In habits: follow the user

If the user’s core action happens in spreadsheets and email, put the MVD there instead of forcing a new portal. The best integration is often the one that respects the habit already carrying the work.