Welcome back to the Fight, Flight, and Freeze series.
In the previous article, we talked in some detail about the “Fight” approach, where organizations choose to modernize their IBM i/AS400 environment by enhancing and extending the value of their existing investments. But over time, it’s important to realize that not every organization views modernization through the same lens.
For some, long-term business objectives, corporate initiatives, organizational changes, or technology roadmaps point toward a different conclusion:
It’s time to move.
This is where the “Flight” approach often comes into play.
Unlike Fight, Flight centers on transitioning away from existing IBM i applications, architectures, or systems in favor of something new altogether. It doesn’t necessarily mean replacing everything overnight. In fact, some of the most successful Flight initiatives unfold gradually over several years.
In this article, we’ll break down what Flight is about and how it can help organizations establish a future-state environment that better supports their long-term business goals.
Key Reasons Organizations Choose Flight
While talking to enterprise owners and business leaders, there are many reasons as to why they choose to migrate away from their long-standing IBM i systems.
In some cases, the decision is driven by broader corporate initiatives. In others, it’s the result of evolving business requirements that existing IBM i applications were struggling to support.
However, the primary drivers observed are often as follows:
- A desire to simplify technology landscapes
- Adoption of standardized ERP platforms
- Application consolidation initiatives
- Enterprise cloud adoption strategies
- Mergers and acquisitions
- Regulatory or compliance requirements
- Workforce and succession planning concerns
Based on this, it’s easy to conclude that teams pursuing Flight typically see IBM i modernization as an opportunity to transform both technology and business processes simultaneously.
As a result, the conversation becomes less about improving what exists today and more about defining what the future should look like.
Flight Isn’t as Simple as Leaving
Another observation is that many organizations believe migration initiatives are primarily technology projects. However, working with many clients transitioning away from their IBM i platforms has highlighted that Flight is often just as much a business transformation effort as it is a technical one.
Applications can be replaced.
Processes can be redesigned.
Data can be migrated.
But organizations must also consider the impact on customers, employees, and partners. Additionally, they must also weigh the effect on reporting processes, operational workflows, and countless other business functions that have developed over many years.
This is often where migration initiatives become more complex than originally anticipated.
The challenge isn’t simply moving to a new platform, it’s ensuring the business continues to operate effectively during the transition.
What Flight Looks Like in Practice
The Flight approach can often take many forms.
For one organization, it involved replacing a homegrown IBM i-ERP application with a cloud-based alternative.
For another, it meant consolidating multiple business systems into a single enterprise platform.
Another chose to adopt an industry-specific SaaS application while gradually retiring their existing IBM i system.
In many cases, we’ve observed that organizations discover migration is not a single event but rather a series of carefully planned milestones.
In a very practical scenario, organizations cannot simply shut down an IBM i system on Friday and start using a new one on Monday. Instead, multigenerational and modern systems often coexist for extended periods while teams validate data, refine processes, and minimize operational disruption.
A story shared by Dmitriy Kuznetsov and Michael Killian (two longtime IBM i industry experts), captures this challenge particularly well.
Real-World Perspective
Dmitriy and his team were helping a US-based environmental services company, with over 25,000 trucks and 60,000 employees, migrate away from their long-standing IBM i environment to a cloud based enterprise resource management system.
The initiative began, as many do, with a change in leadership. The board arrived with a different vision for the technology landscape, and that shift set the stage for everything that followed.
Driving Factors
Internally, the IBM i platform had been viewed, fairly or not, as “legacy” technology. The company operated on hundreds of IBM i/AS400 systems that were becoming fairly difficult and expensive to support. Additionally, the pace of delivering new features and integrations on the existing platform simply wasn’t keeping up with the speed the business needed.
That’s why the leadership team wanted to move away from owning and maintaining custom software altogether, preferring to shift the responsibility to a vendor offering modern, out-of-the-box functionality.
Realizations During Planning
The company grew through rapid mergers and acquisitions that led to fragmented operations. Each business unit had developed their own processes across billing, debt collection, operations, sales, and servicing.
Early on, leadership assumed it would be feasible to consolidate these diverse workflows into a handful of common process templates that every unit could adopt. That assumption met significant resistance from the operations teams, who had built procedures around specific customers and markets.
Another assumption was that the target vendor platform would cover roughly 80% of the required functionality. In reality, it covered less than 50%.
Challenges Faced While Migrating
The systems that needed to be migrated relied on years of tribal knowledge that had never been documented. This led to gaps in understanding how existing business processes and system workflows actually functioned, including hidden direct integrations with customers, partners, vendors, and supporting systems.
Additionally, the preferred platforms for migration were not thoroughly vetted before finalization. Once evaluated closely, they were found to support a much smaller subset of the required functionality than initially expected.
Once migrated, the centralized ERP platform struggled to handle enormous transaction volumes across several business units including customer setups, hauling, landfill, routing, service requests, and ticketing operations. To keep pace, extensive scaling efforts had to be undertaken.
Lessons Learned
This story offers a few key lessons for organizations considering a similar path:
- Confirming that a commercial off-the-shelf product supports at least 70% of the required functionality is crucial before committing significant resources
- Conducting a thorough architectural and business process assessment (one that documents both current and target states in system-agnostic terms) is important to avoid costly surprises later
- Identifying strong migration candidates (such as moving channel partners to an e-commerce platform, HR and payroll to a dedicated HRMS, or sales operations to a dedicated CRM) and migrating in phases can help reduce risk significantly
- Allotting a central space for integration strategy in the migration plan from the outset is essential to keep the business running throughout the transition
The Business Perspective
One theme emerged clearly from the discussion: organizations often make the mistake of treating migration as the end goal rather than a means to an end.
According to Michael Killian, “getting off IBM i” is rarely the true business requirement. More often, organizations are trying to accelerate delivery, enable AI initiatives, enhance customer experiences, improve access to data, increase scalability, reduce reliance on specialized talent, or simplify integrations. Once those desired outcomes are clearly defined, migration may prove to be the right path forward.
He further emphasized that migration is often only one piece of a broader modernization strategy. The more effective approach is to first understand the existing environment, its dependencies, and the business value it provides. From there, organizations can determine what should be retained and modernized, what should be integrated differently, and what genuinely needs to be migrated.
A key takeaway from his perspective is simple:
“Don’t decide to migrate and then build the business case. Define the business case first and let that determine what — and how much — should migrate.”
The Hidden Challenge of Flight
During many migration discussions, we’ve seen clients focus heavily on the destination, that is, getting everything onto the new platform.
However, throughout the experience of our team, we’ve come to realize that the most challenging part of a migration is often what happens in the middle.
However, throughout the experience of our team, we’ve come to realize that the most challenging part of a migration is often what happens in the middle.
- Long-standing IBM i systems continue to support critical business functions
- New IBM i applications are gradually deployed
- Data remains scattered across multiple platforms
- Teams work to maintain business continuity throughout the transition
Here’s what we’ve learned: to ensure a smooth migration, it’s important to emphasize careful planning and coordination during this coexistence period.
Customer information, financial records, inventory data, order status updates, operational metrics, and shipping details must remain synchronized across multiple environments.
Simply put, business cannot stop because a migration is underway.
The Importance of Integration During a Transition
Another observation is that organizations place less importance on integration once they select a new platform for migration.
But in reality, integration often becomes even more important because organizations frequently need to:
- Connect new applications with existing IBM i systems
- Ensure accurate reporting and analytics
- Keep multigenerational and modern applications synchronized
- Maintain visibility into operational processes
- Share data across business units
- Support phased migrations and rollouts
Migration initiatives introduce a new destination but rarely eliminates the need for connectivity.
Oftentimes, we’ve observed that integration becomes the bridge between where an organization is today and where it ultimately wants to be tomorrow.
This idea ties back to a core theme from the introductory article of this series: While the strategies may differ, one requirement remains constant: data must move. Therefore, Flight may change where that data resides, but it doesn’t change the need to make information accessible, accurate, and available when it’s needed.
Common Misconceptions About Flight
Based on stories heard from our greater team surrounding platform migration, the below represents a consolidated a list of widely held myths that many enterprises believe.
Misconception #1: Migration is a single project
Reality: Most organizations discover that migration is a journey comprising multiple initiatives, milestones, and stakeholders.
Misconception #2: Everything needs to change at once
Reality: Successful Flight strategies are often executed in phases, allowing teams to reduce risk and validate outcomes along the way.
Misconception #3: The hard part is choosing new technology
Reality: Managing data, integrations, organizational change, and processes is often far more challenging than selecting the right technology.
Misconception #4: New systems eliminate complexity
Reality: New technologies certainly provide advantages, but complexity rarely disappears. It simply evolves into new forms that must be managed effectively.
When Flight Makes Sense
Here are some of the situations where we’ve seen Flight make the most sense:
- Cloud-first strategies are driving technology decisions
- Enterprise standardization initiatives are underway
- Existing IBM i applications no longer align with long-term business objectives
- Mergers or acquisitions require platform consolidation
- New applications and architectures are believed to support future growth
- Significant business transformation is being pursued
For these situations, migration represents an investment in a future-state vision that extends beyond technology alone.
Final Thoughts
The Flight approach is rarely about abandoning the past. Rather, it’s about building toward a future that better aligns with an organization’s strategic direction.
Organizations pursuing a migration are not necessarily rejecting the value of their existing IBM i systems. In many cases, those systems have successfully supported the business for decades. Rather, they are making a deliberate decision that future business goals require a different foundation.
The most successful Flight initiatives recognize that migration is not only about replacing IBM i applications, but also about ensuring data, people, processes, and technologies remain aligned throughout the journey.
And while the destination may look different from the environment it replaces, one reality remains remarkably consistent:
Data must continue moving between the systems that drive the business.
Moving Forward
Not every organization chooses to modernize by extending existing IBM i systems or migrating to entirely new ones. Some organizations take a more deliberate approach, choosing to preserve their proven IBM i systems while finding new ways to create business value around them.
In the next article, we’ll take a deep dive into why sometimes standing still doesn’t actually mean standing still at all.
