When and How to Refactor Legacy Systems into Microservices

1. When to Refactor Legacy Systems

Legacy system refactoring is both exciting for developers and worrisome for business. Developers enjoy cleaning up old, tangled code and removing unnecessary business logic, while business teams fear that the focus on new development will delay feature delivery.

Refactoring should be considered after weighing cost versus benefit, leadership support, business seasonality, and the team’s proficiency with new frameworks.

2. Current State of the System

Monolithic application with over 200 tables, many holding tens of millions of rows; some tables exceed a hundred million records.

Mixed required and unnecessary business functions, built quickly without strict standards.

Core system tightly coupled with numerous external systems, creating a complex dependency web.

3. Expected Goals

Do not disrupt normal business usage.

Do not affect calls from other systems.

Upgrade the architecture from a monolith to microservices.

Because microservices require database splitting, the migration involves moving tables to new databases across data‑center boundaries.

4. Refactoring Approach

1) Preserve Business Continuity

Develop the new system and database in parallel, keep the old system running, and switch traffic to the new domain once deployment is complete.

2) Preserve Inter‑System Calls

Maintain compatibility with existing interfaces (HTTP, Hessian, RMI) or negotiate new interfaces with dependent systems when possible.

3) Architecture Upgrade

Data migration and upgrade are performed in two phases—initial bulk transfer and incremental sync—using Zookeeper, Kafka, Canal, and Otter. The process includes:

Dumping tables to reduce network bandwidth and recording a dump checkpoint.

Using a temporary backup database on the same server for large‑table transformations without affecting production.

After bulk migration, synchronizing incremental changes from the old database checkpoint to the new one, using Otter for simple field‑to‑field sync or Canal + Kafka + custom consumers for complex business logic.

Switching the application to the new database via a configuration center once data consistency is verified.

Key reminders:

Avoid structural changes to tables unless absolutely necessary.

Thoroughly map and test source‑to‑target fields.

Respect table‑dependency order during synchronization.

Account for the time required to add indexes on large tables.

System and Code Upgrade

Adopt a vertical slicing strategy for business functions and a horizontal slicing for cross‑cutting concerns, avoiding overly fine granularity at the start. The team uses Spring Cloud, leveraging its extensive documentation.

Perform comprehensive functional analysis from both internal (code, tables, jobs, middleware, third‑party calls) and external (log analysis, database access logs, API tracing) perspectives.

5. Reflections

Refactoring a legacy system is like changing a tire on a highway—exciting at the start but fraught with obstacles later. It is essential to define clear boundaries, secure leadership support, and prepare the team for extensive analysis and coordination. As Sun Tzu said, “Know yourself and know your enemy, and you will never be defeated.”