When I introduced this series, I opened with a story about the iPhone 3GS I bought while I was in high school. At the time, it felt like cutting-edge technology to me as it was my first real smart phone (I also had to beg my parents to let me purchase a phone that had data access and an internet plan, and in hand, got one of my first jobs to pay for it – welcome to reality 😊 ). Yet only a year or two later, it struggled to keep up with the apps, features, and expectations that had become commonplace.
That observation led me to a question. If a smartphone can seem to become obsolete so quickly (in my case, be able to support Subway Surfer, Snapchat, as well as multiple gigabytes of videos) how is it that organizations around the world continue to rely on an operating system that traces its roots back to the 1980s? I am, of course, referring to IBM i, an operating system that traces its roots back to the AS/400, first introduced by IBM in 1988.
An Introduction to the Different Types of IBM i Modernization
As I later entered the IBM i ecosystem, I was introduced to the topic of modernization almost immediately. Back then, I thought I had an expert understanding of what modernization entailed. After all, I understood the fundamentals of APIs and integrations and assumed they represented the primary path forward for most organizations.
As you might expect, it didn’t take long for customer conversations to humble me.
The more discussions I had with technology leaders, solution engineers, architects, developers, and business stakeholders, the more I realized that modernization is much, much broader than APIs, integrations, or any single technology initiative. What I initially viewed as a relatively straightforward challenge was actually a collection of competing priorities, business objectives, budget considerations, risk tolerances, and long-term strategic decisions.
Just as I learned that modernization was much more than APIs alone, throughout this series we’ve explored how the concepts of Fight, Flight, and Freeze are often far more nuanced than they first appear. While each approach provides a useful lens through which to view modernization, the reality is that most organizations don’t fit neatly into any one category. And that’s where things start to get interesting.
We’ve learned that some organizations invest in and extend their existing systems through the FIGHT approach to IBM i modernization, while others pursue new applications and platforms through the FLIGHT approach to IBM i migration strategy, and some deliberately preserve trusted systems while modernizing around them using the FREEZE approach to IBM i system preservation.
This framework has proven useful because it simplifies a topic that often feels incredibly complex, especially for those such as myself that had a hard time understanding the concept initially as I had no true technical background prior to my experience in the IBM i field. However, after sharing these concepts, a common question kept surfacing:
What if teams are doing all three modernization approaches at once? Is that possible?
The more thought that has been put into it, the more we’ve realized that this question may actually reveal one of the biggest misconceptions surrounding modernization.
Many organizations assume they need to fit neatly into a single category.
In reality, most don’t.
Most Organizations Don’t Modernize as a Single Unit
When people talk about modernization, it’s often framed as a company-wide decision.
“We’re modernizing.”
“We’re moving to the cloud.”
“We’re replacing legacy systems.”
“Let’s get rid of this green screen.”
In practice, that’s rarely how things unfold.
Most modernization initiatives happen one application, one department, or one business objective at a time. A company may decide to continue investing in its IBM i-based ERP or WMS system because it remains critical to day-to-day operations. At the same time, that same company may replace its CRM with a cloud-based solution, while leaving a stable financial platform largely untouched because it continues to meet business needs.
On paper, that organization appears to be following three different modernization strategies. While this may seem disconnected and unnecessarily complex, in reality, it’s simply making practical business decisions.
That’s why we’ve found that modernization is often less about choosing a single path and more about determining which path makes the most sense for a particular system, process, objective, or an entire ecosystem.
The Business Goal Often Matters More Than the Technology
One of the reasons modernization can be such a challenging topic is that the word itself means different things to different people.
For some, modernization means replacing legacy applications. For others, it means improving customer experiences. Some are focused on cloud adoption, while others still are thinking about analytics, automation, data accessibility, or AI enablement.
The interesting part is that most organizations aren’t actually trying to modernize for modernization’s sake.
They’re trying to solve business problems.
When you take this perspective into account, companies often want better visibility into operations. They want to improve customer experiences. They want access to more timely information. They want to reduce manual processes or support future growth. In the boardroom, once those goals and use cases become clear, the modernization strategy often begins to take shape naturally.
After these goals have been defined, that’s when organizations usually discover that different parts of the business require different approaches.
A Real-World Example
Consider a transportation and logistics company operating a heavily customized IBM i-based transportation management system.
The platform has supported the business for years and remains deeply embedded in daily operations including routing, scheduling, dispatching, and several other functions. Replacing it immediately would introduce significant risk and disruption.
At the same time, business leaders want to improve customer experiences, enhance reporting capabilities, adopt AI-driven forecasting tools, integrate with telematics and fleet management platforms, as well as provide better visibility into operational data.
The company doesn’t necessarily need to replace its core transportation management system to accomplish those goals. Instead, it may choose to preserve the existing application while exposing data to analytics platforms, connecting new customer-facing applications, and leveraging cloud-based technologies where they make sense.
In that scenario, portions of the environment are effectively being Frozen, while other areas are being modernized through Fight-like initiatives. Over time, certain capabilities may eventually migrate elsewhere, introducing elements of Flight as well.
None of these decisions are contradictory. They’re simply responses to different business requirements.
Why Hybrid Modernization Is Becoming the Norm
A decade ago, modernization conversations often centered around large-scale transformation projects. Organizations would spend years planning and executing a single initiative designed to replace an entire platform or application portfolio. Some would succeed, and others would fail—at a significant cost.
In contrast, organizations today have substantially more options available to them. Cloud platforms, APIs, middleware, analytics tools, AI services, and SaaS applications allow teams to modernize incrementally rather than all at once. As a result, many organizations have shifted from asking:
“What should we replace?”
to asking:
“What should we modernize first?”
That’s a subtle but important difference as we talk through these approaches.
The conversation becomes less about choosing a destination and more about identifying where investments will create the greatest business value.
For many organizations, this naturally leads to a hybrid modernization strategy that blends elements of Fight, Flight, and Freeze together.
Where AI Fits into the Conversation
It’s difficult to have a modernization discussion today without hearing about AI.
How can we AI enable legacy applications? How can we do it safely? How can we avoid ending up the news for an AI data leak?
Whether it’s predictive analytics, intelligent automation, customer service enhancements, forecasting, or operational insights, AI has quickly become a priority for many organizations. What’s interesting, however, is that these discussions often reveal a different challenge than people initially expect.
The challenge usually isn’t selecting an AI platform.
The challenge is getting AI access to trusted business data.
As data becomes an increasingly valuable asset, organizations want to leverage the information stored within ERP systems, transportation management platforms, warehouse applications, customer databases, and operational systems, and want to use that information to support decision-making and outcomes that the greater business needs to stay relevant.
As organizations look to implement AI, modernization becomes less about replacing applications and more about making information accessible.
For example, a company may preserve its core business application while modernizing the way that information is exposed. As a result, they can leverage entirely new technologies without disrupting the operations that run the business.
Rather than taking an all-or-nothing approach, organizations can introduce new capabilities where they’re needed while continuing to rely on the systems that support their core operations.
Once again, multiple modernization strategies can coexist within the same initiative.
The One Thing That Hasn’t Changed
If there’s one lesson that consistently surfaced throughout this entire series, it’s this:
While the strategies may differ, one requirement remains constant: data must move.
What’s interesting is that regardless of how organizations define “modernization”, many of them end up addressing the same underlying challenge. Whether they’re implementing a new platform, supporting AI initiatives, improving customer experiences, pursuing cloud strategies, or eliminating manual processes, success often depends on their ability to access and share trusted business data.
This is especially true in the case of a well-established platform like the IBM i. Customer information needs to flow between systems. Operational data needs to be available to analytics platforms. Business applications need visibility into inventory, orders, shipments, financials, and countless other pieces of information that drive daily operations.
The specific modernization strategy may vary, but the need for connected information rarely does.
So… What’s the Right Strategy?
After spending years participating in modernization discussions, we’ve become convinced that this is often the wrong question.
A better question might be:
What’s the right strategy for this specific business objective?
The answer may be Fight. It may be Flight. It may be Freeze.
More often than not, it’s some combination of all three.
The organizations that tend to achieve the best outcomes aren’t necessarily the ones pursuing the latest technology trends. They’re the ones that understand their goals, evaluate each situation individually, and make deliberate decisions based on business value.
Final Thoughts
When we introduced the concepts of Fight, Flight, and Freeze, the goal was never to convince organizations that one approach was superior to another.
The goal was to provide a practical framework for thinking about modernization.
What we’ve learned since then is that most organizations don’t live exclusively within any one category. They’re extending some systems, replacing others, and preserving those that continue to deliver value. And frankly, that’s often a sign of a healthy modernization strategy.
Successful modernization isn’t about putting a label on your organization. It’s about understanding where you are today, where you want to go tomorrow, and what investments will help you get there.
Sometimes that means Fighting, Flying, or Freezing, and more often than not, it means doing a little bit of all three.
