Your legacy application, rebuilt by AI. Proven against the original.
AI-orchestrated refactoring onto a modern stack. AI derives the test cases from your code and documentation, then drives the legacy application and the refactored one together, fixing refactoring defects until the two are functionally identical. Forty years of Sector7 migration work, put in the hands of AI.
- COBOL: programs, paragraphs, calls, files and SQL
- BASIC: VMS BASIC programs and maps
- FORTRAN: routines, common blocks and file access
- C: functions, system service calls and shared data
- MACRO: entry points, transfer vectors and shared sections
- ACMS tasks: tasks, steps, workspaces and exchanges
- ACMS servers: procedure servers and their processes
- ACMS queues: queued tasks and their priorities
- DECnet and TCP/IP: partners the system talks to
- DECforms: forms, panels, records and function keys
- FMS: form definitions and the calls that use them
- TDMS: requests and form definitions
- Rdb: tables, columns, constraints and indexes
- RMS files: sequential and keyed files and who shares them
- CDD: dictionary records and fields
- SQL: embedded statements and the tables they touch
- Global sections: shared memory between programs
- Mailboxes: messages between processes
- Locks: resources held through the lock manager
- Logical names: what is defined, where, and who reads it
- Processes: what is started, spawned and submitted
- DCL: command procedures, jumps and file commands
- Batch and print queues: what runs when
- Message files: status codes and their text
- Linker options: what is built from what
- CICS: transactions, programs and the maps they send
- IMS: hierarchical databases and message transactions
- JCL: jobs, steps and the datasets they use
- VSAM: keyed datasets and who shares them
- Db2: tables, columns and embedded SQL
- PL/I and Assembler: the programs beside the COBOL
- IBM MQ: queues between systems
- RPG: programs, files and calls
- CL: control language programs that start the work
- DDS: display, printer and database file definitions
- Physical and logical files: the database behind the programs
- Data queues and data areas: how jobs pass work and state
- Subsystems and job queues: what runs where
- Shell scripts: what starts what, and in which order
- Embedded SQL: Pro*C and ESQL programs and the tables they touch
- Tuxedo: services, queues and who calls them
- Shared memory and semaphores: how processes cooperate
- cron and batch: what runs when
decisions made by people. The rest is automated.
differences allowed between old and new at the finish.
test cases built by orchestrated AI for one customer system, from its code and its manuals.
the year Sector7 started doing this.
AI does the work. You make three decisions.
Seven stages take a system from source code to proof. Machines run all seven. People step in three times: to confirm the map, to choose the target, and to accept the proof.
Ingest
AutomatedParsers read every source type and write one model.
Map
AutomatedThe model becomes a network you can navigate: programs, data, screens, transactions and operating system objects.
Validate
Your decisionYour experts confirm the map. The parsers list exactly what they could not decide, so this is a review of exceptions, not of everything.
Choose
Your decisionLegacyPhoenix lays out modern stacks and what each means for your system. You pick.
Build
AutomatedGenerators write what rules can write. AI translates the rest, one unit at a time, from the map.
Prove
AutomatedAI drives test cases against the original application, runs the same inputs through the new one and compares the results exactly. In Sector7's current project work this is already happening: on one customer system, orchestrated AI built more than 800 test cases by reading the code and the manuals.
Close
AutomatedEach difference is traced to its cause and fixed, and everything is run again, until none is left. You accept the proof.
No rewriting by hand, no test scripts written by hand, no manual comparison.
One method for every legacy platform.
The method is the same everywhere: parsers map the system, AI rebuilds it, and the original proves the result. What changes from one platform to the next is the set of parsers. OpenVMS comes first because it is where Sector7 has worked longest.
OpenVMS
Working todayVAX, Alpha, Integrity and x86. The working prototype reads COBOL, C, MACRO, ACMS, DECforms, Rdb and DCL here. BASIC, FORTRAN, FMS and TDMS are in development.
IBM mainframe (zSeries)
PlannedCOBOL, PL/I and Assembler, with JCL, CICS, IMS, Db2, VSAM and MQ.
IBM i (AS/400, iSeries)
PlannedRPG, CL and COBOL, with DDS, physical and logical files, data queues and data areas.
Legacy UNIX
PlannedC, C++ and COBOL applications on older UNIX systems, with their shell scripts, embedded SQL, Tuxedo services and shared memory. Sector7 knows this ground: the practice it ran for IBM ported thousands of applications from Sun and HP to IBM Linux and IBM AIX.
AI with something solid under it, and a check on top.
Facts from parsers.
An AI asked to read a large codebase runs out of room and fills the gaps with something that sounds right. LegacyPhoenix builds its map with parsers. Every fact has a file and a line behind it, and what was not modelled is counted and named.
Meaning from AI.
AI is used where judgment is needed: translating a unit, explaining it in plain words, proposing tests. It works on one unit at a time, from the slice of the map around that unit, so it never has to hold the whole system.
Proof from running both.
The original application is the test. The same inputs go through old and new, and the loop ends only when nothing differs.
What an AI-only approach leaves out.
| A typical AI-only approach | LegacyPhoenix | |
|---|---|---|
| How the system is mapped | An AI reads the code and summarises it | Parsers read every source type. Every fact has a file and a line |
| What is on the map | Programs and data | Programs, data, screens, transactions, and the operating system objects between them |
| How you know the new code is right | New tests are written for the new code | The original and the new system run on the same inputs and are compared exactly |
| What you are told at the end | How much code was generated | How many scenarios match, and how much of the system they cover |
| Where your source goes | To a model, in bulk | One unit at a time, to an endpoint you choose, or nowhere with AI off |
| OpenVMS middleware | Not covered | ACMS, DECforms, Rdb, RMS, DCL and the rest are read as first-class sources |
Not the old screens in a browser.
A modern interface.
The converted application gets a new interface for daily use: lists you can search and sort, fields that know their type, and the business words your users already know. The original screens are kept as a second face over the same tasks, because they are the proof at screen level. In development
More options in fields.
Once the original behaviour is preserved, the application can go further: choices offered where the original expected a code typed from memory, sets of allowed values that grow without a code change, and richer inputs for dates, amounts and searches. With every extension off, the system is still the proven equivalent of the original. In development
Built on forty years of migrations.
LegacyPhoenix is a Sector7 product. Sector7 has migrated legacy systems since 1985, and LegacyPhoenix is how that experience becomes software.
Established in October 1985
complex migrations performed since then
VX/TOOLS migration products
patents awarded for migration processes
In more than 40 years, Sector7 has never failed in a migration or rehosting project it has undertaken.
IBM's Migration Factory
In 1997 IBM asked Sector7 to provide a world-wide UNIX to UNIX server consolidation practice. That practice became known as IBM's Migration Factory, porting thousands of applications from Sun and HP to IBM Linux and IBM AIX. In 2003 IBM acquired that server consolidation business from Sector7, with its intellectual property and Sector7's two patents:
- US 7,616,583: Method and program product for consolidating computer hardware resources
- US 8,869,124: Method and program product for costing and planning the re-hosting of computer-based applications
Sector7 was granted a licence to keep using the patents. IBM did not acquire Sector7 or its OpenVMS capability.
Systems Sector7 has already moved.
These migrations were carried out by Sector7's engineers with Sector7's tools. LegacyPhoenix exists to do the next ones faster, with the proof built in.
New York Fire and Ambulance Dispatch System (911)
A real-time PDP-11 system moved to VAX VMS: 400,000 lines of MACRO-11 converted to C, on a home-grown real-time operating system with significant source code missing. A critical system, where failure could result in loss of life.
Read the case study
IKEA
Sector7 migrated all of IKEA's OpenVMS database access from Rdb to Oracle and then to PostgreSQL: over 600 Rdb SQLMOD files, serving stores around the world.
Read the case study
Amprion GmbH
One of the four transmission system operators in Germany. Five million lines of FORTRAN moved from VMS to Linux, in an application that runs in real time and is tightly coupled to VMS system calls.
Read the case studyChicago Stock Exchange
More than one million lines of VAX BASIC, DCL, SORT, RMS, BATCH and PRINT. The migrated system was installed in over 12 international exchanges.
Sector7's historyThe whole system, not one language.
- Languages
- COBOL Working todayC Working todayMACRO Working todayBASIC In developmentFORTRAN In development
- Transaction processing and screens
- ACMS Working todayDECforms Working todayFMS In developmentTDMS In development
- Data
- Rdb and SQL definitions Working todayCDD dictionary definitions Working todayRMS files In development
- Operations
- DCL command procedures Working todaymessage files Working todaylinker options Working today
- Operating system objects
- global sections, mailboxes, locks, logical names and processes, collected from programs, command procedures and build files Working today
- IBM mainframe
- COBOL, PL/I, Assembler, JCL, CICS, IMS, Db2, VSAM and MQ Planned
- IBM i (AS/400)
- RPG, CL, DDS, physical and logical files, data queues and data areas Planned
- Legacy UNIX
- C, C++, COBOL, shell scripts, embedded SQL and Tuxedo Planned
Your source stays where you decide.
Inside your network.
LegacyPhoenix runs on your own machines. Nothing it serves or builds is fetched from outside.
AI off still works.
The map, the validated model and the proof harness are plain code. They work with AI turned off.
You own the result.
The new code is readable, carries references back to the original source, comes with its tests, and can be built without Sector7. In development
Questions we expect.
How do you know the new code is right?
The original application is the test. Recorded inputs are run through the old system and the new one, and outputs, status codes, messages and data are compared exactly. Every difference is traced and fixed, and everything is run again from clean state.
How much of our people's time does it take?
People make three decisions: confirm the map, choose the target stack, and accept the proof. The parsers, the build and the testing loop run without hand work.
What does the AI actually do?
It translates the units that rules cannot translate, one at a time, from the original source and the slice of the map around it. It also explains code in plain words and proposes test scenarios. It does not build the map, and it does not decide whether the result is right. The comparison does.
Does our source code leave our network?
Only if you turn AI on, and then only one unit at a time, to an endpoint you choose. With AI off, nothing leaves.
What can it read today?
The prototype reads COBOL, C, MACRO, ACMS, DECforms, Rdb and SQL definitions, CDD definitions, DCL, message files and linker options from OpenVMS systems. BASIC, FORTRAN, FMS, TDMS and keyed-file migration are in development. IBM mainframe (zSeries), IBM i (AS/400, iSeries) and legacy UNIX systems are planned.
How finished is it?
LegacyPhoenix is in development. A working prototype converts a sample OpenVMS application to Java with a browser front end and replays a recorded set of transactions with identical results. Extending that proof to the whole application is the first goal.