OpenClaw to Hermes Migration (9/13) — Migration Strategy: Strangler Fig Pattern in Practice

The technical case for incremental replacement over Big Bang

ํ•ต์‹ฌ ์š”์•ฝ

What this post covers: - A comparison framework for 5 migration strategies (A–E) applicable to legacy AI agent system transitions - The decision criteria under which the Strangler Fig + Subset Migration (B+D) combination outperforms Big Bang - The concrete structure for securing a rollback path using rsync-based baseline + incremental sync - How an intermediate abstraction layer (memcore) reduces the cost of future migrations

Problem Definition: Why AI Agent Migration Is Not a Simple Move

An AI agent system migration involves more than code. Agent definitions, memory structures, routing logic, and accumulated session archives are all within scope. In this case, the migration covered multiple agents, memory banks, routing, and session archives.

With this scope, a wrong strategy choice converges to one of two failure modes:

  1. Full system halt during migration
  2. Resumed operation post-migration with data loss

Neither is acceptable. Strategy selection therefore becomes a discrete phase in the process.

Comparing 5 Strategy Candidates

From a standard migration pattern catalog, 5 candidates were evaluated in the context of AI agent systems.

Option Name Summary
A Big Bang Full legacy shutdown → full new system launch
B Strangler Fig Feature-by-feature cutover to new system; legacy retires incrementally
C (under review) —
D Subset Migration Migrate a representative subset first; validate, then expand to full scope
E (under review) —

Final selection: B + D combination.

B and D are not mutually exclusive — they are orthogonal. B governs the time axis (when to cut over); D governs the scope axis (what to cut over first). Combined use is valid.

Conditions Under Which Big Bang (A) Is Rejected

Big Bang is structurally simple. Set a cutover date, shut down the legacy system, start the new one. No dual-operation window means low complexity.

However, if any of the following conditions holds, risk exceeds the speed advantage:

  1. Legacy is a layered-patch structure — Long-running systems accumulate incremental patches, creating patch conflicts that surface at bootstrap.
  2. Insufficient time to validate data integrity before cutover — The short transition window of Big Bang makes full agent memory validation impractical.
  3. Rollback cost is asymmetric — When issues surface in the new system, the legacy is already offline. Given accumulated patches, restoration itself is uncertain.

All three conditions apply in this case. A is rejected.

Adopted Strategy: Strangler Fig + Subset Migration

How Strangler Fig Works

Strangler Fig is the legacy replacement pattern named by Martin Fowler. The new system absorbs functionality one unit at a time; the legacy system relinquishes that functionality. As the new system matures, the legacy footprint shrinks. At the final stage, the legacy is removed.

Application model in this case:

Legacy (bank/ continues to be updated)
  → memcore incremental sync
  → New system references only memcore
  → Validation complete
  → Legacy shutdown
  → memcore assumes knowledge base role

How Subset Migration Works

Subset Migration does not move the full scope at once. A representative subset (here: a specific agent group and memory region) is migrated first and validated. On passing validation, the scope expands to the remainder.

Combined Effect of Both Strategies

  • Strangler Fig: Guarantees system continuity. Legacy remains as fallback, so a recovery path exists if the new system fails.
  • Subset Migration: Surfaces risk early before full cutover. Validation failure cost is bounded to subset scope, not full scope.

Implementation Note: Sequential Cutover, Not Concurrent Operation

A common misconception about Strangler Fig: "Both systems process the same requests simultaneously."

This implementation does not do that. A sequential cutover model was adopted.

  1. Legacy stops
  2. New system starts
  3. New system operates on top of the knowledge base transferred via memcore

There is no window where two systems execute agents concurrently. Concurrent execution causes state synchronization conflicts and duplicate billing — both were intentionally excluded. The essence of Strangler Fig is "incremental replacement," not "concurrent operation."

memcore Sync Architecture

memcore is the channel through which knowledge transfers from legacy to new. Sync is split into two phases.

Phase 1: rsync Snapshot (baseline)

The legacy memory state is copied to memcore via rsync. This point becomes the migration reference baseline. All subsequent comparisons and validations are performed against this baseline.

Phase 2: Incremental Sync (delta)

Each time the legacy system adds new information, memcore is updated accordingly. Sync state is maintained up to the final cutover.

Automation

LaunchAgent com.memcore.sync.plist executes sync daily at 03:30 KST.

<!-- com.memcore.sync.plist — key section -->
<key>StartCalendarInterval</key>
<dict>
    <key>Hour</key>
    <integer>3</integer>
    <key>Minute</key>
    <integer>30</integer>
</dict>

The 03:30 KST slot avoids peak evening activity and targets a low-load window, minimizing lock contention during sync.

Rollback Path Design

Recovery procedure if issues arise after new system cutover: restart legacy.

Because memcore is based on snapshots generated by legacy, restarting legacy resumes operation on the same knowledge base. No data loss.

The availability of this rollback path is one of the core reasons Strangler Fig was selected.

Strategy Rollback Cost
Big Bang High — legacy state must be reconstructed; uncertain restoration due to accumulated patches
Strangler Fig Low — legacy is preserved up to the baseline snapshot

Low rollback cost also means the new system can be trialed aggressively. This is the technical foundation for decision-making agility.

Strategy Selection Criterion: Portability First

The guiding criterion for strategy selection:

"Does this decision also make the next migration easier?"

This is the principle of prioritizing long-term portability over short-term convenience. The new system will eventually become a migration target itself. The current architecture should be helpful when that time comes.

This is why memcore exists as an intermediate abstraction layer. Direct dependencies on legacy internals are not passed to the new system. As long as the memcore interface is maintained, the next replacement — new → successor — can repeat the same pattern at the same cost.

That is: memcore is an abstraction boundary that amortizes replacement cost.

Applicability and Limitations

Cases Where This Applies

  • Legacy systems with long operational history and accumulated patch layers
  • AI agent, bot, and pipeline systems where accumulated knowledge/state is critical
  • Production systems where rollback path availability is a top priority
  • Cutover timelines not constrained by hard business deadlines

Cases Where This Pattern Is Weak

  • Fundamental data model incompatibility between legacy and new system (intermediate layer design cost becomes prohibitive)
  • Short cutover deadline where baseline maintenance cost exceeds that deadline
  • Monolithic state machines where a natural subset boundary does not exist

Summary

Item Decision
Strategy Strangler Fig + Subset Migration (B+D)
Rationale for rejecting Big Bang Accumulated patch conflicts → asymmetric rollback cost
Concurrent operation None. Sequential cutover.
Sync mechanism rsync baseline + incremental delta (03:30 KST)
Rollback Legacy restart. No data loss.
Long-term portability mechanism memcore abstraction layer

Open Questions

  • How is the representativeness of the selected Subset measured? To what degree does passing subset validation guarantee full-scope success?
  • What is the migration cost when memcore's schema diverges from the data model of the next-generation system?
  • What is the tolerable drift window between legacy and memcore during the incremental sync interval?

Series overview: Series index

๋Œ“๊ธ€

๋Œ“๊ธ€ ์“ฐ๊ธฐ