Migration from old schema to new schema

You changed your mind. Now everything downstream is wrong.

You decide that "being a good manager" means coaching people to solve their own problems instead of solving problems for them. A genuine update. You believe it on Tuesday. By Thursday you've already jumped in to fix a broken deployment, rewritten a junior engineer's PR description, and scheduled three meetings you could have delegated. Not because you forgot what you believe — but because every system around you was built on the old schema.

Your calendar reflects the old version. Your team's expectations reflect the old version. Your muscle memory when Slack pings at 9 PM reflects the old version. The belief changed. The infrastructure didn't migrate.

This is the fundamental problem of schema migration: updating a mental model is not the same as updating everything built on top of it. And the gap between those two events is where most personal change efforts die.

Schema migration is a systems problem, not a willpower problem

In software engineering, no one would update a database schema and expect the application to magically adapt. When a column name changes, every query referencing that column breaks. When a data type changes from string to integer, every function that processes that field needs rewriting. This is so well understood that entire categories of tools exist to manage the process.

Flyway and Liquibase — the two dominant database migration frameworks — treat schema changes as versioned, sequential operations. Each migration is a numbered script. Each script transforms the data and structure from version N to version N+1. The tools enforce ordering, track what has been applied, and prevent you from running a migration out of sequence. The critical insight is that migration is not optional. When the schema changes, the migration must happen, or the system breaks.

Stripe, which processes hundreds of billions of dollars in payments, takes this even further. Their API uses date-based versioning — each version is pinned to a release date like 2024-10-01. When Stripe changes the API, every existing integration continues to work on its pinned version. But the migration path is explicit: developers can send a Stripe-Version header to test the new version, run both versions side by side, and upgrade when ready. The old version isn't pretended away. It's supported until the migration is complete.

Now apply this to your own cognitive systems. When you update a schema — your understanding of leadership, productivity, relationships, risk, identity — you don't get to just update the belief and walk away. Every decision, habit, routine, expectation, and commitment that was built on the old schema is now running on an outdated version. Some will keep functioning with minor friction. Others will silently corrupt your new understanding until you wonder why the change "didn't stick."

The problem was never willpower. The problem was that you migrated the schema but not the system.

The cascade: why one change breaks five things

Jean Piaget identified this dynamic in children's cognitive development in the mid-20th century, and the mechanism applies equally to adult belief systems. Piaget distinguished between assimilation (fitting new information into existing schemas) and accommodation (modifying schemas to handle information that doesn't fit). What makes accommodation expensive is that schemas are interconnected. Modifying one schema creates disequilibrium — a state where connected schemas no longer cohere — which forces further accommodation or produces internal conflict until balance is restored.

Cognitive behavioral therapy research confirms this cascade in clinical settings. A 2014 study published in Frontiers in Psychology modeled belief revision as a non-linear dynamical system, showing that changing one core belief doesn't produce a single, clean update. It produces a period of instability across connected beliefs, which must individually settle into states compatible with the new core. The researchers found that belief revision is the key change mechanism underlying CBT, and that it both motivates and reinforces new behavior — but only when the downstream beliefs are also addressed.

This is why changing your mind often feels worse before it feels better. You've entered disequilibrium. Your new schema about what "good work" looks like now contradicts your old schema about what "a responsible person does." Your new schema about healthy boundaries contradicts your old schema about being dependable. The new schema is correct. But correctness doesn't resolve the conflict — migration does.

Think of it as a dependency graph. Your belief that "I should respond to every email within an hour" might depend on:

• A schema about professionalism ("responsive people get ahead")
• A schema about self-worth ("my value is in being available")
• A schema about risk ("if I don't respond fast, bad things happen")
• A habit of checking email every 15 minutes
• A notification configuration on three devices
• An implicit contract with your team about response times

Update the top-level schema to "I should batch email twice a day" without migrating any of those dependencies, and you'll be back to checking email every 15 minutes within a week. Not because the new schema was wrong, but because six downstream structures are still running the old version and generating constant pressure to revert.

How organizations get this right (and how you can too)

John Kotter's research at Harvard Business School, drawn from observing hundreds of organizational transformations, identified why most change efforts fail: they treat change as an event rather than a migration. His 8-step process for leading change, published in 1996 and refined over three decades, reads like a schema migration protocol:

1. Create urgency — Establish why the old schema is no longer viable
2. Build a coalition — Identify all the systems and stakeholders connected to the old schema
3. Form a vision — Define the new schema clearly
4. Communicate the vision — Make sure every dependent system knows the migration is happening
5. Remove obstacles — Identify structures that block the migration
6. Create short-term wins — Migrate the easiest dependencies first to build momentum
7. Build on the change — Migrate progressively harder dependencies
8. Anchor in culture — Ensure the new schema is the default, not the exception

Kotter reported that more than 70% of change efforts that followed this full process succeeded, while most that skipped steps — particularly the downstream migration steps — failed. The pattern is clear: updating the schema (steps 1-3) is necessary but nowhere near sufficient. Steps 4-8 are the migration.

You can apply the same protocol personally. When you update a significant mental model:

1. Name the old schema and the new schema explicitly
2. Map every downstream dependency (habits, commitments, relationships, tools, routines)
3. Prioritize: which dependencies create the most friction with the new schema?
4. Migrate the highest-friction dependencies first
5. Accept that some dependencies will take weeks or months to fully migrate
6. Monitor for reversion — old dependencies pulling you back to the old schema

The point is not to migrate everything simultaneously. That's as unrealistic for a person as it is for a database with a billion rows. The point is to have a migration plan, execute it incrementally, and track your progress.

The AI parallel: transfer learning and catastrophic forgetting

Artificial neural networks face a strikingly similar problem. When a model trained on Task A is retrained on Task B, it tends to forget how to do Task A — a phenomenon McCloskey and Cohen (1989) described as "catastrophic forgetting." The model's weights, which encoded the old knowledge, are overwritten by the new training data. The old schema is destroyed rather than migrated.

The AI research community has developed several strategies to manage this, and each one has a direct analogue in personal epistemology.

Transfer learning preserves the foundational layers of a trained model while retraining only the upper layers for a new task. The model keeps its general knowledge (how to recognize edges, shapes, and textures in an image model) and only updates the task-specific layers. The parallel: when you update a schema, you don't need to rebuild your entire worldview. Identify which foundational beliefs remain valid and only migrate the layers that directly depend on the changed schema.

Knowledge distillation trains a smaller "student" model to replicate the behavior of a larger "teacher" model — compressing knowledge without losing critical capabilities. DeepSeek-R1, for example, distilled reasoning capabilities from larger models at a fraction of the computational cost. The personal parallel: when you migrate a schema, you can distill the lessons from your old schema into a compact form ("that model was wrong about X, but the discipline it taught me about Y still applies") rather than discarding everything the old schema produced.

Experience replay combats catastrophic forgetting by periodically re-exposing the model to examples from previous tasks while learning new ones. This keeps old knowledge accessible even as new knowledge is acquired. The personal parallel: after a schema migration, periodically revisit the contexts where your old schema used to operate. Check whether your new schema handles those cases. This is how you prevent the migration from creating gaps — and it's exactly what the next lesson on backwards compatibility addresses.

The stability-plasticity dilemma in neural networks — the tension between retaining old knowledge and incorporating new knowledge — is the same tension you feel during any significant belief change. Too much stability, and you can't learn. Too much plasticity, and every new insight overwrites the last one. Effective schema migration balances both: preserve what works, update what doesn't, and maintain a clear record of what changed and why.

The migration protocol

Here's how to execute a schema migration in your own knowledge system:

Step 1: Document both versions. Write down the old schema and the new schema side by side. "Old: productivity is hours worked. New: productivity is problems solved." If you can't articulate both versions clearly, you haven't finished defining the migration.

Step 2: Map the dependency graph. List every habit, commitment, tool, relationship, and routine that was built on the old schema. Be thorough. The dependencies you miss are the ones that will pull you back to the old version.

Step 3: Classify each dependency. For each item in your graph, mark it:

• Already compatible — works with the new schema without changes
• Needs migration — must be updated to align with the new schema
• Needs deprecation — no longer makes sense under the new schema and should be removed
• Blocked — can't migrate yet because of external constraints

Step 4: Migrate in order of friction. Start with the dependency that generates the most daily conflict between your old infrastructure and your new understanding. That's where the energy cost of non-migration is highest.

Step 5: Run both versions temporarily. Just as Stripe lets developers pin to an old API version while testing the new one, you may need to run both schemas in parallel for a transition period. Your team expects the old version of you. You can't switch overnight without creating chaos. Communicate the change, give people (and yourself) a migration window, and phase out the old version gradually.

Step 6: Test for regression. After migrating each dependency, check whether your new schema actually holds up in that context. Sometimes a downstream migration reveals that your new schema needs refinement — and that's information, not failure.

The real failure mode

The most common failure in personal schema migration isn't picking the wrong new schema. It's doing the intellectual work of updating the belief while skipping the structural work of updating the system. You read a book about deep work and believe focused blocks are superior to constant availability — but your calendar, your notification settings, your team norms, and your guilt response are all still running on the "always available" schema.

The insight feels like change. It isn't. Change is when the downstream systems are migrated.

L-0307 covered the debt that accumulates when you know a schema is wrong but don't update it. This lesson covers what happens after you update it: the migration work that turns an insight into an operational reality. And L-0309 will address the next problem — making sure your new schema can still handle the cases your old schema covered, so the migration doesn't create new gaps while closing old ones.

The primitive holds: when you update a schema, you must also update everything built on top of it. Not because it's tidy. Because until you do, the old version is still running your life.