PYD ENTERPRISES and Backstage

Make the legacy estate visible where developers already look

Platform teams use Backstage as the map of everything that runs. Legacy systems are usually missing from that map, or present as a single stub component with no APIs and no owner. PYD ENTERPRISES generates catalog descriptor files from what it actually found in the code, so the mainframe loan system appears in the catalog with its real interfaces and dependencies next to the new services that will replace it.

For each scanned system PYD ENTERPRISES writes:

• A System entity for the legacy application, with owner and description.
• A Component entity per deployable unit it identified (a CICS region's transaction group, a batch job stream, an EAR, an IIS application).
• An API entity per synthesized interface, with spec.type: openapi or asyncapi and a definition that points at the generated document.
• providesApis, consumesApis and dependsOn relations derived from the dependency graph: CALLs and LINKs, EJB lookups, WCF client proxies, shared DB2 or Oracle tables declared as Resource entities.

How the files reach the catalog

PYD ENTERPRISES writes the descriptor files into the specification repository it exports to (GitHub, GitLab, Bitbucket or Azure Repos). You register that repository location with your Backstage catalog once, using whichever discovery or location configuration your platform team already uses, and from then on each approved scan updates the entities through a normal commit. PYD ENTERPRISES does not need access to your Backstage instance.

Entity names are stable across scans, derived from system and program names, so relations and links from other entities do not break when PYD ENTERPRISES regenerates the files.

Using the catalog during modernization

Once legacy APIs are in the catalog, new services can declare consumesApis against them, and the dependency view shows exactly which new components still lean on mainframe interfaces. As each capability moves, the replacement service's API entity takes over the relations and the legacy API can be marked with a deprecated lifecycle. The catalog becomes a running record of how much of the old system is still in the path.