	In Browser
	StumbleUpon
	del.icio.us
	Google
	Google Buzz
	reddit
	LinkedIn

	Facebook
	Twitter
	Linkedin
	E-Mail

Data Migration > Zero-Downtime Migration > Strangler Fig Pattern for Legacy Migration

Strangler Fig Pattern for Legacy Migration

Author: Venkata Sudhakar

The Strangler Fig pattern is a software migration strategy inspired by the strangler fig tree, which grows around an existing tree and gradually replaces it over years. In software migration, you build a new system alongside the existing legacy system and incrementally route features and traffic to the new system, one piece at a time, until the legacy system is completely replaced and can be decommissioned. At no point during the migration is the service unavailable to users.

This pattern is particularly powerful for monolith-to-microservices migrations and legacy database modernisations. A routing layer (a proxy, API gateway, or feature flag system) sits in front of both the old and new systems. Initially all requests go to the old system. As each module or feature is rewritten and tested, the routing layer redirects those specific requests to the new system. The rest continue going to the legacy system unchanged. This allows teams to migrate at their own pace without a high-risk "big bang" rewrite.

The below example shows how to implement a Strangler Fig routing proxy in Spring Boot that routes customer-related API calls to the new microservice while routing all other calls to the legacy monolith.

import org.springframework.web.bind.annotation.*;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Mono;

@RestController
@RequestMapping("/api")
public class StranglerFigProxy {

private final WebClient legacyClient = WebClient.create("http://legacy-monolith:8080");
    private final WebClient newServiceClient = WebClient.create("http://customer-service:9090");

// MIGRATED: Customer endpoints now route to new microservice
    @GetMapping("/customers/{id}")
    public Mono<String> getCustomer(@PathVariable String id) {
        System.out.println("Routing GET /customers/" + id + " -> NEW customer-service");
        return newServiceClient.get()
            .uri("/customers/" + id)
            .retrieve()
            .bodyToMono(String.class);
    }

@PostMapping("/customers")
    public Mono<String> createCustomer(@RequestBody String body) {
        System.out.println("Routing POST /customers -> NEW customer-service");
        return newServiceClient.post()
            .uri("/customers")
            .bodyValue(body)
            .retrieve()
            .bodyToMono(String.class);
    }

// NOT YET MIGRATED: Orders still route to legacy monolith
    @GetMapping("/orders/{id}")
    public Mono<String> getOrder(@PathVariable String id) {
        System.out.println("Routing GET /orders/" + id + " -> LEGACY monolith");
        return legacyClient.get()
            .uri("/api/orders/" + id)
            .retrieve()
            .bodyToMono(String.class);
    }

// NOT YET MIGRATED: Inventory still routes to legacy monolith
    @GetMapping("/inventory")
    public Mono<String> getInventory() {
        System.out.println("Routing GET /inventory -> LEGACY monolith");
        return legacyClient.get()
            .uri("/api/inventory")
            .retrieve()
            .bodyToMono(String.class);
    }
}

It gives the following output when requests are made,

Routing GET /customers/1001 -> NEW customer-service
Routing POST /customers -> NEW customer-service
Routing GET /orders/5001 -> LEGACY monolith
Routing GET /inventory -> LEGACY monolith

The below example shows how to use feature flags with AWS AppConfig to control the routing dynamically at runtime, allowing you to switch individual endpoints from legacy to new without redeploying the proxy.

import software.amazon.awssdk.services.appconfigdata.AppConfigDataClient;

@Component
public class MigrationFeatureFlags {

// Feature flag keys - controlled via AWS AppConfig console
    // without any code deployment
    private static final String FLAG_CUSTOMERS = "migrate.customers";
    private static final String FLAG_ORDERS = "migrate.orders";
    private static final String FLAG_INVENTORY = "migrate.inventory";

@Autowired
    private AppConfigDataClient appConfigClient;

public boolean isFeatureMigrated(String featureKey) {
        // Fetch latest config from AWS AppConfig
        // Returns true when the feature has been switched to new service
        String config = appConfigClient.getLatestConfiguration(
            r -> r.configurationToken(getToken())).configuration().asUtf8String();
        // Parse JSON config and return flag value
        return parseFlag(config, featureKey);
    }
}

// In the proxy controller:
@GetMapping("/orders/{id}")
public Mono<String> getOrder(@PathVariable String id) {
    if (featureFlags.isFeatureMigrated("migrate.orders")) {
        // Orders migration is done - route to new service
        return newOrderServiceClient.get().uri("/orders/" + id)
            .retrieve().bodyToMono(String.class);
    } else {
        // Still on legacy
        return legacyClient.get().uri("/api/orders/" + id)
            .retrieve().bodyToMono(String.class);
    }
}

It gives the following output,

# Before enabling flag in AppConfig:
Routing GET /orders/5001 -> LEGACY monolith

# After enabling "migrate.orders" flag in AWS AppConfig
# (no deployment needed, takes effect within seconds):
Routing GET /orders/5001 -> NEW order-service

# Instant rollback: just set flag back to false in AppConfig

Migration Progress Tracking:

At any point in the Strangler Fig migration, you can measure progress as the percentage of API endpoints or traffic that has been switched to the new system. A typical enterprise migration might take 6 to 18 months, with each sprint completing one or two more modules. The legacy system is only decommissioned when 100% of traffic has been moved and the new system has been running stably in production for a defined period, usually 30 to 90 days.

Send your comments, suggestions or queries regarding this site to [email protected].