Data-Layer Decoupling

Unlock legacy data for cloud innovation while preserving your business logic.

Modern enterprises are sitting on mountains of critical data locked away in legacy systems. These data stores—often DB2 or IMS databases accessed via embedded SQL in COBOL programs—are essential for business operations but make modernization risky and costly.

A rip-and-replace approach forces businesses to choose between rewriting millions of lines of code or staying trapped in the past. Data Layer Decoupling offers a third path: separating data access from business logic so enterprises can modernize databases without rewriting entire applications.

This pattern makes it possible to:

• Migrate or modernize data gradually, rather than all at once.
• Support hybrid architectures where some data remains on-prem while new workloads use modern cloud databases.
• Unlock legacy data for analytics, AI, and modern applications—without waiting years for a full rewrite.

Data Layer Decoupling turns your legacy data into an asset rather than a barrier.

What Is the Data Layer Decoupling Pattern?

In traditional mainframe applications, business logic and data access are often deeply entangled. This tight coupling:

• Prevents moving workloads to modern databases like PostgreSQL, Aurora, or NoSQL.
• Increases risk and complexity for modernization.
• Blocks real-time analytics and cloud adoption.

Definition: Data Layer Decoupling is a modernization pattern that removes direct, embedded SQL calls from legacy programs and replaces them with API-based data services. This allows legacy applications to connect to modern databases without rewriting business logic.

OpenLegacy’s Data Layer Decoupling pattern extracts embedded SQL calls from legacy code and replaces them with remote, API-based SQL services. This allows your applications to:

• Access modern databases without changing core business logic.
• Scale data modernization independently from application modernization.

When to Use Data Layer Decoupling

You want to migrate backend data **without rewriting **entire COBOL or RPG applications.

Your modernization roadmap includes moving to cloud-native databases e.g., PostgreSQL, MongoDB).

You’re aiming to enable AI, analytics, or new digital services that depend on modern data access.

Step-By-Step Implementation with OL Hub Planner

1. Discover & Analyze: Use the OpenLegacy Hub Planner to scan code, detect embedded SQL, and visualize data dependencies.
2. Generate Integration Factory Assets: Automatically generate remote SQL services as REST APIs. Create data proxies that translate API calls back into legacy SQL.
3. Refactor Data Access: Replace embedded SQL calls in the legacy code with remote API calls.
4. Deploy in Phased Coexistence: Run data proxies on z/OS USS, Linux, or Kubernetes. Support hybrid deployments accessing both legacy and modern databases simultaneously.
5. Observe & Optimize: Leverage built-in observability for performance monitoring and security (OAuth2, RBAC). Gradually shift traffic to modern databases.