Legacy code modernization is a portfolio problem, not a single project. Most enterprises do not have one aging codebase. They have several, in different languages, on different stacks, with different risk profiles and different business criticality. The question is rarely “should we modernize this one application.” It is “given limited budget, attention, and developer capacity, which legacy systems should move first, and how.”

This framework is for IT leaders running portfolios that include both IBM i (RPG) and Laravel (PHP) applications. The two stacks are not similar technically, but the modernization decisions follow the same logic. The shop that runs a 30-year-old IBM i banking system is often the same shop that runs an 8-year-old Laravel admin tool that has not been upgraded since the original developer left.

The framework below applies to both. The tooling answer is different. The decision process is not.

The Five-Question Framework

Before any modernization project starts, the team running the portfolio should be able to answer five questions for every legacy application under consideration.

Question 1: What does this application actually do?

Not what the runbook says. What it actually does. Includes: the business functions it serves, the data it touches, the integrations it consumes and produces, the users who depend on it, the failure modes that have been observed.

For applications where the original team is still present, this question is answerable. For applications where the original team is gone, this question is the first deliverable of any modernization effort. Without it, every subsequent decision is guesswork.

Question 2: What depends on it?

The dependency graph. Every program, file, service, integration point, and downstream consumer. In IBM i this means called programs, copy members, service program references, triggers, and SQL views. In Laravel this means controllers, services, models, jobs, events, observers, packages, and external API consumers.

Most “modernization is harder than expected” stories trace back to underestimating the dependency graph. A program that looks isolated turns out to feed three other systems. A Laravel service called from a single controller turns out to also run in a queue job that no one remembered.

Question 3: What is the risk of doing nothing?

Not “what if we never modernize.” That is rhetorical. The real question: what is the risk of doing nothing for 18 months while we focus on something else.

For IBM i RPG, the risk is usually talent. Engineers who maintain the application retire. The pool of available replacements shrinks. Eventually the application becomes unmaintainable not because it broke, but because no one can change it safely.

For Laravel, the risk is usually security and dependency rot. Laravel 6 is end of life. PHP 7 is end of life. Packages get deprecated. Vulnerability disclosures accumulate. The application keeps running until the day it does not, or the day an audit demands a patch that requires upgrading a chain of dependencies.

Question 4: What is the cost of doing it badly?

Failed modernizations are not free. The cost is the original project budget plus the cost of running both the old and the new systems during the failed parallel period plus the opportunity cost of the team that was not available for other work plus the trust deficit with leadership when the next modernization comes up for approval.

The historical failure rate of large modernization projects is high. Better tooling reduces but does not eliminate this risk. The framework should account for failure scenarios, not just success scenarios.

Question 5: What does modernization actually look like for this specific application?

Not “modernization in general.” This application specifically. The answer is different for an RPG batch processor than for an RPG interactive screen system than for a Laravel admin portal than for a Laravel public API.

The output of this question is a written scope. Not a roadmap slide. A document that describes what will change, what will not change, what tooling will be used, what the parallel period looks like, what the rollback plan is, and what success looks like.

How the Framework Applies to IBM i (RPG)

IBM i modernization in 2026 is fundamentally different from IBM i modernization in 2018 because the tooling category has changed. The current generation of AI-driven modernization platforms (AS/Forward from Golden Path Digital, IBM’s own offering, emerging competitors) builds a deterministic dependency graph and generates plain-English program descriptions before the AI ever touches the code.

This changes the answers to the framework questions:

• Question 1 (what does it do) becomes answerable in weeks, not years. The tool ingests the source code and produces the documentation that does not exist.
• Question 2 (what depends on it) becomes a visualization, not a research project. The dependency graph is the tool’s primary output.
• Question 3 (risk of doing nothing) stays the same. Talent cliff. Audit pressure. Change paralysis.
• Question 4 (cost of doing it badly) drops because the tool-assisted approach has a meaningfully better track record than full hand rewrites or lift-and-shift to a different IBM i instance.
• Question 5 (what modernization looks like) becomes specific to the application: convert to free-format RPG, convert to Python, or assessment-only. The right answer depends on the customer’s broader stack.

The recommended entry point is an assessment engagement. The output is a complete codebase inventory plus a written modernization plan, delivered in weeks. From that document, the CTO can decide whether to proceed and what scope.

How the Framework Applies to Laravel

Laravel applications are smaller, younger, and less load-bearing than typical IBM i workloads, but the modernization decisions follow the same logic. The applications most at risk are the ones that:

• Are running on Laravel 6, 7, or 8 (all past EOL or approaching it)
• Are running on PHP 7 (EOL)
• Have not been actively maintained for 12+ months
• Have a package.json or composer.json with no recent updates
• Run in production but have no test suite to validate behavior

The traditional answer was “upgrade Laravel by hand, one major version at a time.” For a Laravel 6 application targeting Laravel 11, that is five major version transitions, each requiring breaking-change review and code refactoring. A team that does this full-time can move an application from Laravel 6 to 11 in weeks; a team that does this on the side stretches that to months.

Automated tooling now exists for this. Laravel Ascend (open source, GitHub repository at github.com/goldenpathdigital/laravel-ascend) automates the upgrade path, applying code transformations for breaking changes and reducing the manual work substantially. The framework questions still apply: what does the application do, what depends on it, what is the risk of doing nothing, what is the cost of doing it badly, what does the specific upgrade look like.

The answer to “what does the specific upgrade look like” for a Laravel 6 to Laravel 11 transition has shifted from “engage a contractor for three months” to “run the tooling, review the diffs, run the test suite, deploy.” Not zero work. Substantially less work.

Sequencing the Portfolio

For shops running both IBM i and Laravel legacy applications, the question of which to modernize first comes down to four factors:

1. Risk profile. An IBM i banking system has higher risk than a Laravel admin portal. The banking system goes first if either is going to fail.
2. Talent exposure. If the RPG team has one engineer left and they are within five years of retirement, the IBM i moves to the front of the queue.
3. Compliance pressure. If an audit cycle is coming and one application has documented gaps, that one goes first regardless of the other factors.
4. Tooling readiness. AS/Forward exists. Laravel Ascend exists. Other categories of legacy code may not have equivalent tooling yet, which changes the cost calculus for those projects.

The portfolio approach is what separates strategic modernization from reactive modernization. Reactive modernization waits until something breaks, then chases it. Strategic modernization sequences the work according to risk and tooling availability, ahead of the failure modes that would force the work.

Common Mistakes

1. Treating modernization as one project instead of a portfolio. Different applications, different tools, different sequences. A single “modernization roadmap” that covers everything always underestimates.
2. Underestimating dependency graphs. Always larger than the team thinks. Assessment tooling exists for IBM i; static analysis tooling exists for Laravel. Use them before scoping.
3. Choosing the tool before the framework. The right tool depends on the framework answers. Buying tooling before asking the five questions produces tool-driven decisions instead of business-driven decisions.
4. Skipping the assessment engagement. An IBM i modernization plan written by someone who has not seen the actual codebase is fiction. Assessment first, decision second.
5. Trying to do this without leadership air cover. Modernization projects require sustained executive sponsorship through the inevitable schedule slips. Without it, projects stall when other priorities arise.

Golden Path Digital and the Modernization Stack

Golden Path Digital builds tooling for both ends of the framework. AS/Forward is the IBM i modernization platform: deterministic ingestion of RPG codebases, dependency graph generation, plain-English program descriptions, multi-target output (modern RPG, Python, others), and air-gapped deployment for regulated industries. 1 US patent pending. Laravel Ascend is the open-source Laravel upgrade automation tool: runs Composer-based, handles version transitions from Laravel 6 through 11, available on GitHub.

The two tools serve different segments of the same portfolio modernization problem. Both reduce the cost and risk of legacy code modernization in ways that were not possible five years ago.

What to Do Next

If your portfolio includes IBM i RPG, the next step is an assessment engagement to answer the framework questions for your specific codebase. If your portfolio includes aging Laravel applications, the next step is to evaluate Laravel Ascend against your upgrade backlog and identify which applications are candidates for tooling-assisted migration.

Visit goldenpathdigital.com/as-forward/ or goldenpathdigital.com/laravel-ascend/ for product details, or reach out via the contact form to discuss your specific portfolio.

Golden Path Digital is an enterprise software and AI modernization company headquartered in Hot Springs Village, Arkansas. AS/Forward modernizes IBM i and RPG codebases. Laravel Ascend automates Laravel application upgrades. QuantaPath AI delivers HIPAA-compliant CRM and workflow automation. Serving enterprises nationwide with US-based delivery and air-gapped deployment options. 1 US patent pending.