DMS, our deterministic toolkit that combines symbolic AI and enhanced compiler technology, in production since 1995, migrates your Natural and ADABAS workloads to the .NET stack you already run. ADABAS files become SQL Server tables. Natural and COBOL become C# on ASP.NET Core. Gen AI handles the adjacent work, like business rule extraction and test generation.
After cutover, your modernized application runs as a standard .NET solution that your development and operations teams already know how to build, deploy, monitor, and maintain. The specialized runtime environments and proprietary infrastructure required by Natural and ADABAS are replaced with industry-standard Microsoft technologies, allowing your applications to integrate seamlessly with the rest of your enterprise architecture.
ADABAS data is transformed into a fully normalized relational database such as SQL Server or Azure SQL. Natural programs become native C# applications running on ASP.NET Core, while COBOL or PL/I applications that previously accessed ADABAS use standard ADO.NET or Entity Framework Core to access the new relational database. Predict metadata is converted into strongly typed Entity Framework Core models, providing developers with familiar, maintainable data access patterns that can be extended using standard .NET practices.
Modernization extends beyond the application itself. EntireX services become RESTful ASP.NET Core APIs, ApplinX terminal screens become modern web applications using Blazor or Razor Pages, and legacy batch processing can be deployed as Azure Functions, Hangfire jobs, scheduled services, or Azure Data Factory pipelines based on your operational requirements. The completed solution integrates naturally with Visual Studio, Azure DevOps, GitHub Actions, SQL Server Management Studio, and the rest of your existing Microsoft development ecosystem. The result is a modern, cloud-ready application built on open standards, without the cost, complexity, and constraints of the mainframe.
Naive translators handle one or two of these well and the rest poorly.
The job is handling all five.
Each ADABAS Multi-Value (MU) field is transformed into a normalized child table related to its parent record through a foreign key and occurrence index. The generated data access layer preserves the original natural access semantics, allowing application behavior to remain unchanged while taking advantage of a standard relational database.
Periodic (PE) groups become normalized child tables, with each occurrence stored as a separate row linked to its parent record. Sequence information is preserved so application behavior remains identical. The modernized application accesses these structures through standard object-relational mapping or database access frameworks appropriate for the target platform.
An ADABAS Internal Sequence Number (ISN) is a physical record locator rather than a stable business key. During modernization, DMS translates ISN-based access to relational key access. When the customer has identified appropriate business primary keys, those keys are used directly. Otherwise, DMS generates surrogate primary keys with the appropriate indexes to preserve application behavior and performance.
ADABAS superdescriptors are composite search keys derived from portions of one or more fields rather than stored columns. DMS automatically generates the equivalent implementation for the target relational database. SQL Server uses persisted computed columns with indexes, while Oracle, PostgreSQL, and Db2 use native expression indexes. The translated application uses these indexes transparently, preserving query behavior without requiring application changes.
Many ADABAS environments include COBOL or PL/I applications that access ADABAS directly through the ADABAS call interface rather than through Natural. DMS translates these database operations into equivalent relational database operations while preserving transaction boundaries, locking behavior, and application semantics. The remainder of the COBOL or PL/I application is modernized using the same deterministic transformation technology used throughout the project.
Modernizing an application requires more than translating code; it requires moving decades of critical business data without compromising integrity or disrupting operations. Modernize Software automatically generates a custom data migration solution that moves ADABAS data to modern relational databases such as Oracle and Microsoft SQL Server. By automatically translating ADABAS Data Definition Modules (DDMs), DMS creates a purpose-built migration application that extracts data directly from ADABAS, writes it to an optimized binary format, and loads it into the target SQL database with deterministic precision. The result is a fast, repeatable, and reliable migration process that eliminates the cost and risk of hand-written conversion scripts.
Unlike traditional data migration approaches that treat application and database modernization as separate projects, Modernize Software generates the data migration tool from the same metadata and compiler technology used to transform your Natural or COBOL applications. This ensures the target SQL database is fully compatible with the schema expected by the modernized application. Every table, column, relationship, and data type is synchronized with the transformed code, dramatically reducing integration risk and eliminating costly post-migration rework.
For organizations that require a phased modernization, Modernize Software also supports coexistence between the legacy ADABAS environment and the new relational database. We collaborate with leading third-party data synchronization vendors to provide near real-time synchronization between the two databases, enabling parallel operations, incremental cutovers, and comprehensive validation before final migration. The result is a low-risk modernization strategy that preserves business continuity while accelerating the move to a modern, open architecture.
Two layers. Translation runs on DMS. Discovery and review run on Gen AI.
The split matters because government and financial natural and ADABAS workloads can’t tolerate silent semantic drift. Gen AI guessing what an L3 call means is a defect.
ADABAS for Mainframe on z/OS and z/VSE (versions 7 and 8)
ADABAS on BS2000
ADABAS for Linux, Unix, and Windows
ADABAS C, the classic inverted-list engine, and ADABAS D, the separate relational product that later became SAP DB and MaxDB
ADABAS SQL Gateway (CONNX-based) sources
MU fields and PE groups including MU-within-PE nesting, elementary and sub-descriptors, superdescriptors, hyperdescriptors, phonetic descriptors, null suppression, and fields defined with the fixed-storage FI option.
ISN-based access, L1/L2/L3 reads, S1/S2/S4 finds, ET/BT transactions.
DBID, FNR, file definitions from Predict or ADAREP.
Direct CALL ADABAS from COBOL, PL/I, and Assembler, across the control block, format buffer, record buffer, search buffer and value buffer: OP and CL session control, L1 to L6 record reads, L9 histogram, S1, S2, S4, S8 and S9 finds and sorts, A1 update, N1 and N2 store, E1 delete, ET and BT transaction control, and RC and RE command-ID release.
FIND, READ, HISTOGRAM, STORE, UPDATE, DELETE statements.
ADASEL, ADAREP, ADAULD, ADACMP for data extraction.
Natural is covered here alongside the data migration. For the language on its own,
Four phases, run in sequence with rolling delivery from full migration onward.
ADABAS metadata and surrounding sources go through DMS. You receive a complexity report flagging MU/PE density and custom call inventory, plus a fixed-price quote inside 10 business days. The assessment is free.
We migrate five to ten ADABAS files plus the Natural and COBOL programs touching them. You compare against the original for functional equivalence. The pilot is measured against a 95% functional equivalence threshold.
Module deliveries every four to six weeks, and data load scripts that run repeatedly for refresh as you test.
The new .NET stack alongside Natural and ADABAS, processing the same inputs and comparing outputs. When the diff reaches zero, you cut over.
Your DBAs maintain SQL Server or Azure SQL instead of ADABAS. Familiar tools (SSMS, Azure Data Studio); familiar query language (T-SQL instead of ADABAS direct calls and Natural DML); and standard backup, log shipping, and availability group patterns instead of ADASAV, ADARES, and PLOG procedures.
Your developers work in C# instead of Natural and COBOL. The skills are easier to hire for. The tooling (Visual Studio, ReSharper, and Rider) is mature. Documentation reads in the same English the rest of your codebase uses.
Your ops team deploys through your existing pipeline. Azure DevOps or GitHub Actions, depending on what you run. Application Insights for observability. Standard .NET monitoring instead of Software AG-specific telemetry.
A legacy hierarchical database had outlived its usefulness: modern applications could not access the data and support costs were rising. The legacy data manipulation language differed sharply from relational SQL, so the existing programs could not read a new schema without being rewritten, and the model differences had to be mapped first. We handled all of it on one toolkit. DMS analyzers recovered the legacy data model, the rearchitect pass converted the programs to relational access, and a data migration tool moved and cleaned the records during cutover. For a Natural and ADABAS to C# project the work is identical in shape: the DDM-defined data and the Natural programs above it, converted together into .NET and SQL Server.
ADABAS structures like ISNs, Period Groups, and Multiple Value fields have no direct relational mapping. Recovering them by hand is where projects stall. Deterministic analysis recovers the structure from the real access patterns in the code, which is what makes the relational schema trustworthy at cutover.
General questions
C# is the right natural and ADABAS migration target when your team works in .NET, your target cloud is Azure, or your stack is Microsoft-centric. SQL Server and Azure SQL pair naturally with C# repositories. We also deliver Natural and ADABAS to Java for teams on the JVM targeting AWS or GCP.
MU fields become child tables with a foreign key to the parent and an occurrence index. PE groups also become child tables, one per group, with the parent reference plus a sequence number. EF Core repository methods reproduce the original access pattern so application code behaves the same.
Natural and ADABAS to C# migration targets 95% to 99% functional equivalence in final delivery. The remaining 1% to 5% covers constructs requiring human review: custom natural macros, application-specific superdescriptor logic, and undocumented business rules. The pilot calibrates the rules against your codebase before full migration is scoped.
A typical migration covering 500 ADABAS files and 1 million lines of surrounding Natural and COBOL runs 6 to 12 months end-to-end. Smaller installations (100 to 200 files) finish much faster.
Migration is scoped per project, not per line of code. Cost depends on codebase size, dialect coverage, how much surrounding code has to move with it, and the target architecture. The free assessment produces a fixed-price quote for the whole engagement, locked for 90 days, so the number is settled before any translation work starts.
Yes. Some natural and ADABAS to C# migrations include all three languages because the two are almost always deployed together, and many shops also have COBOL or PL/I with direct ADABAS calls. CALL ADABAS sites in COBOL and PL/I get rewritten as ADO.NET blocks. Natural translates to C# end-to-end.
ADABAS is fast on its specific access patterns. A naive migration performed by some vendors will be slower. Our process includes performance profiling during pilot and full migration. Queries that miss the original benchmark get rewritten before cutover, and indexing gets tuned per-table. Most production cutovers reach 1:1 or better throughput on SQL Server.
The free assessment delivers six artifacts in 10 business days: a complexity report, a relational data model preview, a sample migration of 2 to 3 ADABAS files with the code that reads them, a risk register, a phased project plan, and a fixed-price quote locked for 90 days. The assessment is free.
A successful modernization project is measured by one outcome: the modernized application must produce the same business results as the legacy system. Our deterministic DMS technology is designed to retain every business rule while generating clean, maintainable Java or C# code that behaves like the original application. DMS is validated through thousands of automated translator unit tests, your existing functional, regression, integration, and performance tests are executed against the new application, and parallel operation of the legacy and modernized systems is supported for organizations requiring the highest level of assurance.
Cutover is the moment your traffic shifts from Natural and ADABAS to the new C# and SQL Server stack. Before it happens, a parallel run has shown zero difference between systems for the period you chose (typically 3 to 6 months). After it happens, ADABAS data stays archived, and the legacy system remains available read-only for a defined rollback window. Most clients keep the rollback open for 90 days before decommissioning.
Send your metadata. Complexity report and fixed quote in 10 business days.
.png)
info@semanticdesigns.com
