We have overused the word "legacy." It gets stamped on IBM i by people who have never signed on to one, who don't understand what the platform can actually do, and who judge it by its problems instead of its possibilities.
I'll be honest: I royally hate that term, especially when it's used to describe IBM i.
To be clear, I'm not trying to retire the word entirely. When "legacy" refers to old code, bad coding practices, monolithic nightmares, or systems that are out of support, it's the right word. Use it. But applying that same label to a platform capable of doing so much more is just inaccurate.
So how do we overcome the word "legacy"? Not with a better comeback. With a practice.
That practice is modernization, and it is not a single project or a product you buy. It is a way of working, and it has an order. It doesn't start in one place. It starts in many, usually with a business need. Maybe an old application can't connect out to UPS or FedEx for shipping rates and orders. Maybe your database is holding your applications hostage, running so slowly you can go get a cup of coffee before your report finishes. All of it affects how well a business can grow and pivot.
This work doesn't happen overnight. It happens in steps, and the first one always starts at the business level.
Start with the business
What is the business need you're trying to accomplish? Answer that first. Then ask what existing business processes you have in place that need to be reviewed and improved. What are the new business requirements?
Then get specific. Who owns this process today, and who needs to be in the room when you change it? Who actually uses it every day, and what slows them down? What does success look like once this is done, and how will you measure it? Steps removed, hours saved, orders processed, errors caught before they ship. If you can't measure it, you can't prove the modernization worked.
Ask what it costs to do nothing. That answer sets your priority. Ask what is in scope and what is not, because a project without edges never ships. Ask what other systems, teams, and vendors this process depends on, and what breaks upstream or downstream when it changes.
This stage can take a while, but it's vital. It's the foundation everything else sits on.
Then think about security
Who is going to access this application, and how? Hosted or on prem? Access tokens through APIs, or user logins? Do we need MFA?
Then keep going. Where do the identities come from? Are you tying into Active Directory or an identity provider, or managing users on the box? Authentication only gets someone through the door. What are they allowed to do once they are inside? Define the roles, and give each one the least access it needs to do the job, at the object level, not "everybody gets *ALLOBJ and we sort it out later."
What data is involved, and how sensitive is it? Customer records, card data, health information, anything that carries a regulation with it. That answer decides how much of this you encrypt, in transit and at rest, and it tells you which compliance framework you are on the hook for, whether that is PCI, HIPAA, SOX, or a state privacy law, and what each one requires you to log and keep.
Speaking of logging, who did what, when, and can you prove it later? Plan the audit trail now, not after an auditor asks for it. Plan for the bad day too. If a credential leaks or a token is stolen, how do you revoke it, and how fast?
Notice that I haven't mentioned a lick of code yet. That's on purpose. If you start with the code, you're starting in the middle. Business comes first. Security comes next.
Now you can talk architecture
Architecture is not "which language." Language is a detail you pick later. Architecture is about structure: what the pieces are, where they run, and how they talk to each other.
Start with the shape of the application itself. What are the layers? You want business logic separated from the interface and from data access, not tangled together the way it probably is today. That means deciding which logic belongs in service programs with clean, callable interfaces, which orchestration sits above them, and where the boundaries are drawn so one change doesn't ripple through everything.
Then the interface layer. Is this a web UI, an API, or both? If there's a UI, what framework is it built in, and what does it call? If there's an API, that's an architectural component in its own right, and you need to decide where it lives and what hosts it: IWS, WebSphere Liberty, or an open source web server on the platform. That choice drives how you deploy, how you scale, and how you support it.
Then integration. This modernization probably exists because the old application couldn't reach out to UPS, FedEx, or some other service. Those outbound calls are part of the architecture too: where they originate, how failures and timeouts are handled, and how you keep a slow third party from dragging down the rest of the system.
Then the runtime picture. What runs where? What talks to what, and over which protocol? How is access to the web server locked down? Where do configuration and connection keys live? Not in source, so where? Are you on TLS 1.2 or 1.3?
Notice how security came back into the conversation. That's the point. It's part of every architectural decision, not a phase you pass through once. Answer these questions and you know where the application lives and how it holds together before a single program is written.
Then, and only then, the nitty gritty
Once you know where the application is going to live and how it's locked down, you can get into the details. This is where most people want to start, and it is still the last thing on the list.
Code structure:
- Which existing programs do we pull business logic out of and isolate into a service program?
- Which monolithic program do we need to break into smaller pieces?
- What new programs, modules, and procedures do we need, and what do their interfaces look like?
- Are we converting fixed format RPG to free format as we go, and are we holding new code to a coding standard so we don't just rebuild the same mess in a newer syntax?
Data:
- Do the tables stay as they are, or do we move from DDS to DDL and SQL defined tables?
- Where do primary keys, foreign keys, constraints, and referential integrity belong now that the database can enforce them instead of every program doing it by hand?
- What new indexes and views does the access path need?
- Is journaling on for every file that matters, and are we using commitment control where we should be?
- How do we convert and migrate the existing data, and how do the old and new stay in sync while both are still running?
Quality and support:
- What do error handling and logging look like, and are they consistent across every new program?
- How do we monitor this once it is live, and how do we get alerted when something breaks?
- Where are the unit and regression tests, what data do they run against, and do they run automatically?
- Is the source in Git, and is there a real build and deployment process instead of hand promoting objects?
APIs and contracts:
- What is the contract for each API, where is it documented, and how do we version it when it changes?
- What happens to a caller when a downstream service is slow or down?
Rollout:
- Do we cut over all at once or in stages?
- What is the rollback plan if the cutover goes wrong?
Answer these questions, make sure you've covered every business requirement, and document every step. When you're done, you have a business problem documented from the very beginning all the way through to how you'll solve it and what you need to do it.
Legacy is the wrong word
That sequence is the practice. Business first. Security next. Architecture after that. Code last. Document every step.
Follow that order and you don't end up with a rewrite. You end up with a business problem solved on purpose, on a platform that was never the problem.
That is how you overcome the word "legacy." Not by arguing about it. By making it inaccurate.
Because this is the system running the world. You just don't see it. It's behind the shipping label, the invoice, the payroll run, and the bank transaction, stable and ready for whatever the business asks next.
Call that legacy if you want. I call it the foundation.