Harvesting Shared Primitives Before Monorepo Rewrites

Total rewrites get funded because reading legacy code is harder than writing new code. When an internal monorepo accumulates five years of framework churn and ad-hoc patches, the codebase looks indefensible. The architectural drift makes every change feel dangerous, and the engineering team asks for a blank slate.

The failure mode of the blank slate is architectural amnesia.

What looks like technical debt in an established codebase is often operational scar tissue. It is the defensive null-check for an undocumented API response, the date parser that handles three different upstream time formats, or the retry delay tuned after a specific database incident. When you scrap the system to start over, you do not just discard old frameworks. You discard years of production bug fixes and re-open solved failure modes.

The Cost of the "Clean" Rebuild

When a team rewrites a system from scratch, they typically consult the specification rather than the running code. But specifications describe how the system was intended to behave, not how the external world actually behaves.

If you rebuild a data-ingestion pipeline against the documented API of your upstream vendors, the new service will look pristine. It will also crash on day one when an upstream vendor sends an empty string instead of a null, or encodes an integer as a float. The old, ugly code handled that case because a developer patched it at 2:00 AM three years ago.

Refactoring does not mean preserving the entire monolithic architecture. It means separating framework churn from verified business logic. The architecture may need to be replaced, but the core domain calculations, string parsers, and validation rules inside it are assets.

The Harvest Pattern

Instead of choosing between living with technical debt or throwing away working logic, extract load-bearing primitives before tearing down the surrounding service.

1. Audit for framework-free logic. Run a targeted repository audit across the services scheduled for decommissioning. Identify utilities, parsers, and state machines that do not depend on the web framework or database driver.
2. Isolate the inputs and outputs. Pull the candidate logic out of the controller or job handler into an isolated file.
3. Capture historical edge cases. Write unit tests that assert the function's behaviour against real production edge cases—especially the malformed data the legacy code was patched to handle.
4. Publish as an internal primitive. Move the isolated code into a shared internal library or package.

// Extracted primitive: retains vendor quirk handling without framework dependencies
export function normalizeTransactionPayload(raw: unknown): NormalizedTransaction {
  if (!raw || typeof raw !== 'object') {
    throw new TypeError('Invalid payload structure');
  }
  // Preserves legacy fix for undocumented legacy upstream timestamp format
  const timestamp = parseVendorTimestamp((raw as Record<string, unknown>).created_at);
  return {
    id: String((raw as Record<string, unknown>).id),
    timestamp,
    amountCents: parseAmount((raw as Record<string, unknown>).amount),
  };
}

By extracting these functions into standalone artifacts, you make the subsequent rewrite safer. The new service can be built using modern tooling while importing the battle-tested logic directly. This approach is central to cataloguing in-tree utilities to prevent duplicate work and preserving hard-won operational fixes across rewrites.