I have a strange relationship with AS400 systems.
I say AS400 because that is still what most people call them, even though IBM has renamed the platform enough times that keeping track of the branding feels like a small certification exam. AS400, iSeries, System i, IBM i. The names changed. The green screens kept quietly running businesses.
I started programming RPG when I was about twelve, working around my dad’s company. That sounds slightly ridiculous now, but it is true. While normal kids were doing normal kid things, I was learning about files, records, reports, job queues, printer output, and the strange beauty of business systems that did exactly what they were supposed to do without needing applause.
So when people talk about AS400 and IBM i systems as if they are embarrassing relics, I have to be a little careful not to twitch.
There is probably some nostalgia in that, and I should admit that up front. Some people get nostalgic about old cars, old hockey cards, vinyl records, or the smell of a wood shop. I apparently get a little nostalgic around green screens, RPG code, printer files, and the sound of a dot matrix printer doing its angry little song in the corner.
So yes, I am weird.
But I am not only nostalgic. I am also cautious, because I have seen these systems run real businesses. I have seen old RPG programs quietly contain more accurate business logic than the modern software someone wanted to replace them with. I have seen green screens that look ancient but let a trained user move faster than a shiny web app that needs three spinners, two modals, and a motivational quote before it lets you enter an order.
That is why I do not like treating AS400 systems as jokes.
I can joke about them. I grew up with them. That is different.
I get it. The screens look old and the workflows can feel old. There may be a dot matrix printer somewhere making noises that sound like a robot trying to fax a lawnmower. Some of the code may have been written before half the staff were born. None of that is ideal, but old is not the same thing as stupid.
In many businesses, the AS400 is not the problem.
It is the part that still works. The problem is often everything that grew around it.
Ugly systems survive for a reason
There is a reason these systems are still around, and it’s not nostalgia. It is not because everyone secretly loves green screens. It is not because business owners wake up in the morning thinking, “You know what would really spark joy…? Function keys, 24 of them.”
These systems survive because they do important work: They run inventory. They manage orders. They handle accounting workflows. They produce invoices, reports, labels, pick tickets, work orders, purchase orders, statements, and all sorts of business documents nobody thinks about until they stop appearing at the right time.
They also contain business logic, and that is the part people underestimate.
An AS400 system is often not just a database with old screens. It is decades of decisions, exceptions, customer-specific rules, pricing logic, approval paths, reporting habits, operational shortcuts, and “we do it this way because of that one thing that happened in 2007 and nobody wants it to happen again.”
That logic may be buried in RPG programs, CL scripts, print files, menu options, queries, reports, and the muscle memory of people who have been using the system for years.
A modern developer may look at the green screen and see something outdated, but a business analyst should look at it and ask, “What does this system know that nobody has written down?”
That is usually where the money is.
The printout is not always the problem
One of the easiest mistakes in legacy modernization is to look at an old process and assume the visible ugly part is the problem.
A dot matrix printer looks old, so people assume the printer is the problem. A green screen looks old, so people assume the screen is the problem. A carbon copy form looks old, so people assume the form is the problem.
Sometimes that is true. but often, it is not. In fact, often it’s the exact opposite.
The printer may be ugly, but the real purpose might be routing information to three departments. The form may be ugly, but the real purpose might be authorization, colour-coded handling, customer confirmation, internal filing, and audit history. The green screen may be ugly, but the real purpose might be fast data entry by staff who can process work faster than someone clicking through a beautiful modern interface with seven loading animations and a hefty per user subscription fee. Which is why I get nervous when someone says, “We just need to replace the old system.”
Maybe… But before replacing anything, we should understand what the old system is actually doing.
Not what people think it is doing…
Not what the screen appears to be doing…
Not what the vendor brochure from 1998 said it was doing, which is 90% of the time totally wrong.
What it is actually doing in the business today.
Sometimes the AS400 is holding the business together
A lot of companies have an old IBM i or AS400 system sitting quietly in the middle of the business. Newer systems orbit around it. The website may have been rebuilt. The CRM may be newer. Accounting may have changed. Staff may be using spreadsheets, email, cloud folders, mobile apps, and modern reporting tools.
But the AS400 is still there.
It is still the system of record for something important: Orders. Inventory. Customer data. Pricing. Production. Billing. History. Documents. Some strange combination of all of the above. Which creates a funny situation. Everyone talks as if the modern tools are the business system, but when someone really needs to know what happened, they still go back to the AS400.
That should tell us something, something very important and foundational. The old system may not be fashionable, but it may still be authoritative.
This is where enterprise integration matters. The question is not always “How do we get rid of the AS400?” Sometimes the better question is,
“How do we let the rest of the business talk to the system that still knows the truth?”
That can mean reporting improvements, or better exports or APIs (XMLService anyone?). It can mean middleware, replacing one piece of the workflow, building a better intake process on the website and connecting it to the older system behind the scenes, or creating a modern interface for one specific process instead of rewriting the whole platform.
Modernization does not always mean replacement. Sometimes modernization means building a sane bridge.
Rewriting what you do not understand is a good way to create a very expensive mystery
There is a particular kind of confidence that appears before a bad rewrite. It usually sounds like this:
“The old system is ancient. We will just rebuild it in something modern.”
That sentence should make everyone in the room sit up a little straighter and the hair go up on the back of their neck.
Not because rebuilding is always wrong. In fact, sometimes it is the right move. Some systems really do need to be replaced and some old code is brittle. Some hardware situations are risky and some workflows are too constrained. Some skills are becoming harder to find and some businesses cannot keep depending on one person who understands the entire system.
But rewriting a legacy system before understanding it is dangerous, incredibly dangerous.
The old AS400 system may contain rules nobody remembers. It may have reports that are used only once a quarter but are critical when they are needed. It may have exception handling for a few major customers. It may have hidden approval logic. It may have assumptions about inventory, credit, pricing, taxes, shipping, returns, or document flow that nobody explains because everyone has been living inside the system for too long.
When you rewrite without understanding those things, you do not get a clean modern replacement, you get a modern-looking system that is missing fundamental pieces of the business. A system that looks like it’s working correctly until it fails for that big customer at the absolute worst time. A system that is missing that one report that’s essential to business process, but now requires significant reworking with a “modern” system.
This is worse. The new system is fancy and shiny and might lie to you, but at least the old system was honestly old.
The knowledge problem is often bigger than the technology problem
The scariest part of many AS400 and IBM i environments is not the age of the system. It is the concentration of knowledge.
There is often one person, or a very small group of people, who really understand the old system. They know which reports matter. They know which jobs need to run. They know which menu options are safe. They know which printer output goes where. They know which file names mean something important. They know which program everyone is afraid to touch.
That person may be brilliant. That person may also be retiring.
Or tired.
Or overloaded.
Or already gone.
Then the business discovers that its documentation is mostly folklore.
This is not a criticism. It is simply a fact of life, business systems grow over years and people solve problems, make changes, remember things, and train the next person informally. They build little rituals in the process and eventually the actual system is partly in the machine and partly in people’s heads.
That is why business analysis is not optional in legacy modernization.
Before you decide what to replace, integrate, document, support, or rebuild, you need to map the actual process. You need to understand the screens, reports, files, outputs, exceptions, users, departments, and downstream systems. You need to know what the business would lose if the old system disappeared tomorrow.
That sounds dramatic, but it is one of the most important questions.
Old systems can be better designed than new ones
Maybe I’m truly old school and I know this is the part that annoys modern software people, but it is often true.
Some older business systems are ugly but extremely coherent. They were built around the actual business. They may not be pretty, but they know the workflow. They know what the warehouse needs. They know what accounting needs. They know what the customer service person needs to see. They know which field matters.
A lot of modern software, by contrast, is beautiful right up until the moment it meets a real business process, then everyone discovers the demo was more polished than the workflow.
Don’t get me wrong, this is not a rant against modern software. Panda Rose builds modern software. We build custom software, web applications, integrations, websites, and business systems. I like modern tools when they are used properly, but I do not like the assumption that new automatically means better.
A modern system that does not understand the business is not an upgrade. It is just a nicer interface wrapped around a misunderstanding. The old AS400 may have ugly screens and brilliant business logic. The trick is knowing which part to preserve and which part to replace.
The real pain is usually at the edges
In many AS400 environments, the core system still works. The pain is usually at the edges. Without deep knowledge, careful consideration and understanding of the underlying systems…
Getting data out is painful.
Reporting is painful.
Connecting to the website is painful.
Sharing data with a CRM is painful.
Modernizing forms is painful.
Replacing old print workflows is painful.
Giving staff a cleaner interface for one specific task is painful.
Integrating with cloud tools is painful.
Supporting the people and infrastructure around the system is painful.
That is not necessarily an AS400 failure. It is often an integration problem, a workflow problem, a reporting problem, or a support problem.
This is why managed IT support, enterprise integration, custom software development, and website development can all end up touching the same legacy system. The system may need to keep running, but the business around it needs better access, better reporting, better automation, better support, or better interfaces.
That is a very different conversation than “rip it out.”
There are usually three sane options
When a business has an old AS400 or IBM i system, there are usually three sane directions.
- The first is to stabilize and support it. That means making sure backups, access, documentation, monitoring, vendors, hardware, hosting, security, and support are not being held together by luck and memory. Sometimes the best immediate move is simply to reduce risk.
- The second is to integrate around it. That means connecting the system to newer tools, better reporting, web forms, CRM workflows, customer portals, dashboards, or operational systems. This often gives the business a lot of value without the risk of a full rewrite.
- The third is to replace or rebuild parts of it. Sometimes the legacy system really does need to be replaced. Sometimes a specific module or workflow should become a modern application. Sometimes the old system should become less central over time. But that should usually come after the business understands what the system actually does.
The dangerous option is the fourth one:
Vague Modernization: That is when everyone agrees the old system is old, everyone agrees something should be done, and then nobody slows down long enough to define the thing that actually needs fixing.
That is how companies spend a fortune modernizing the wrong problem.
AS400 experience is weirdly rare now
This is where I have to admit my background is unusual, possibly bordering on ridiculous.
I have been around RPG and AS400 systems since I was a kid. Not “I read about it in a white paper” around them. Actually around them. Green screens, reports, printer files, business records, weird menu structures, the whole thing. I was young enough that “working with legacy systems” sounds absurd, because at the time they were not legacy systems. They were just the systems I got to play with.
There are not many people my age with that kind of exposure. I sometimes joke that I may be one of the youngest people in North America with more than thirty years of AS400 experience, which is both a flex and a slightly troubling statement about how old I am getting.
But it matters, because this kind of work benefits from someone who can speak both languages.
You need to understand the older system well enough to respect it. You also need to understand modern software, websites, databases, integrations, cloud tools, SEO, managed IT, and business operations well enough to build around it intelligently.
If you only understand the old system, you may preserve too much, and if you only understand the new tools, you may break something important because you did not know why it existed.
The value is in the bridge.
That is really what Panda Rose tries to bring to these situations.
Preserve what works. Fix what hurts.
I do not think legacy modernization should start with contempt. If an AS400 system has been running a business for decades, it deserves some respect. It may be ugly. It may be awkward. It may be full of things that need to change. But it probably also contains a lot of hard-won business knowledge. The right question is not, “How do we get rid of this old thing?”
The better questions are:
- What does this system still do well?
- What business logic does it contain?
- What depends on it?
- Where are the real bottlenecks?
- What reports or outputs are still critical?
- Which workflows are painful because of the AS400 itself?
- Which workflows are painful because newer systems were never integrated properly?
- Who understands the system today?
- What knowledge is at risk of walking out the door?
- What can be improved without disrupting the whole business?
- What should be documented before anyone touches anything?
- What should be wrapped, integrated, replaced, or left alone?
That is a less exciting conversation than “digital transformation,” but it is a much safer one, and usually a more profitable one.
The old machine may not be the villain
The AS400 is easy to blame because it looks old, but the old machine may not be the villain.
The villain may be undocumented business logic, or disconnected systems, or old reports nobody has reviewed, or manual re-entry, or a print workflow that made sense twenty years ago but no longer fits, or one person holding too much knowledge, or a modern system that never learned how to talk to the older one.
Sometimes the answer is custom software development. Sometimes it is enterprise integration. Sometimes it is better managed IT support. Sometimes it is a better website intake process. Sometimes it is reporting. Sometimes it is documentation. Sometimes it is leaving the AS400 alone and fixing everything around it.
That judgment is the hard part.
If your business depends on an AS400 or IBM i system, and you are not sure whether the right answer is support, integration, modernization, reporting, documentation, or replacement, Panda Rose can help map what the system actually does before anyone starts swinging a hammer.
Start with a Legacy Systems Review, and we can help figure out what should be preserved, what should be fixed, and what should be modernized carefully.
