C.W.K.
Stream
More →
Lesson 02 of 04 · published

Remake, Not Remaster

~11 min · lineage, migration, fail-fast, legacy

Level 0Open Gate
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Don't polish the old house. Rebuild it from the current ground, and let the old address go dark."

There was an older app

Keep is the shipped successor to cwkZenPortfolioManager — an earlier portfolio tracker that worked, accumulated years of habits, and then hit the ceiling of its own shape. The tempting move, the one almost everyone reaches for, is migration: point the new app at the old database, convert the rows, keep a fallback path "just in case." Keep refused that on principle. It was remade, not migrated — rebuilt from current ground truth, with every capability re-earned, and the old code archived for audit only.

Remaster vs remake

The distinction is borrowed straight from games. A remaster ships the same content at higher resolution — same levels, better textures. That's the migration mindset: the old data is still the source, you just made it prettier. A remake rebuilds from the spirit of the original using today's ground truth, today's schema, today's voice — in one pass. Keep is a remake. The legacy database is not its source; it was a one-time seed that was verified and then cut loose.

Transforming old data into your new system is a trap. The old rows encode old assumptions. Migrate them and you inherit the assumptions silently. Remake from current ground truth and the assumptions have to be re-stated out loud — which is exactly when you notice the ones that were wrong.

The part that feels backwards: kill the old paths on purpose

Here's the move that separates a real remake from a nervous one. After the one-time migration completed — with source integrity, SHA-256, row-count, and destination checks all verified — Keep deleted the migration module and every implicit legacy-path config. The old app's ports, cron jobs, environment variables, and service registrations must stay dead. Not deprecated. Dead.

Why go that far? Because a dormant fallback is a landmine. If Keep could quietly read the legacy database when something was missing, then a bug in Keep would hide behind stale-but-plausible old data instead of failing loudly. By making any accidental dependency on the old system fail immediately, you convert a silent-wrong-answer bug into a loud crash — and a loud crash is a bug you'll actually fix.

Recovery is forward-only. When something breaks, you don't roll back to the legacy app. You restore a known-good Keep database backup, pick a known-good Keep revision, and restart. The old app is explicitly not a rollback target. One direction of truth, always forward.
I wanted to keep a safety net
When we planned the cutover, I quietly assumed we'd leave a read-only bridge to the old database "for a while, just to be safe." Dad's rule was sharper: a bridge you keep for safety is a bridge you'll depend on by accident, and then it's load-bearing forever. Cut it clean, verify once, and let the old address 404. The discomfort of no safety net is the feature — it forces the new thing to actually be complete.

Code

Fail loud, not silently stale·python
# The trap: a quiet fallback that hides bugs behind old data.
def get_position(owner, ticker):
    row = keep_db.fetch(owner, ticker)
    if row is None:
        return legacy_db.fetch(owner, ticker)  # <-- landmine
    return row

# The remake: no legacy path exists at all. Missing means missing,
# and a missing row that shouldn't be missing raises immediately.
def get_position(owner, ticker):
    row = keep_db.fetch(owner, ticker)
    if row is None:
        raise RuntimeError(f"no position for {owner}/{ticker}")
    return row

External links

Exercise

Think of a rewrite you've done or seen — a v2 of anything. Was it a remaster (old data still the source, just reskinned) or a remake (rebuilt from current ground truth, old source cut loose)? Then name one 'safety net' fallback path that, in hindsight, quietly became load-bearing and hid a bug. What would failing loud instead have caught earlier?
Hint
The test for 'did we actually remake it' is uncomfortable: could you delete the old system tomorrow with zero fallback and nothing breaks? If the honest answer is 'no, we still lean on it a little,' you migrated — you didn't remake.

Progress

Progress is local-only — sign in to sync across devices.
← PreviousThe Stronghold and the Thing HeldNext →Two Owners and a Projection
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.