Avoid costly difficulties and setbacks to your application modernization projects and smoothly transition to the modern applications your business deserves!

So, you're ready to take your 5250 green-screen applications into the 21st Century. Great! You're not alone—IBM has made modernization a major focus for its IBM i business, and companies are responding positively.

The benefits of modernizing your IBM i applications have been well-documented but are worth mentioning again. Because today's workforce expects to use browser-based, point-and-click applications, it's much easier to train users on these types of applications rather than green-screen applications. Web-based applications have more "real estate" than 5250 screens and are capable of features, like scrolling and tabbed panels, that enable users to work more productively. And since modern applications can be served up in mobile devices, businesses can support their out-of-office workforce with anywhere/anytime access to IBM i applications.

For the business, application modernization makes sense as it is significantly more cost-effective than replacing the IBM i server with a "more modern platform" (a point we'll get to in a minute). Even modernizing RPG code (for example, free-format instead of fixed) makes applications easier to develop, scale, and maintain—which is good news for IT shops that have soon-to-retire developers or that deal with large amounts of legacy code.

Once the decision to modernize is made, the real work starts. Over the years, as I've worked with them on their modernization projects, I've realized that some companies have a much smoother transition from green-screen to modern apps than others. Here are the top five pitfalls I've seen companies stumble into when modernizing—and tips for how to avoid them!

1) Not Defining Modernization Goals
Right from the start, you should have the following conversation with the team responsible for the project: "What do we want to accomplish by modernizing our applications?" It sounds simple, but you would be surprised at how many companies skip this step! Modernization goals can include improving application adoption by improving the user experience, updating legacy RPG code to make it easier to maintain, and creating mobile applications to support out-of-office employees. As with anything, the more preparation and planning you do up front, the easier the task is at the back end.

Taking the time to define your modernization goals can also help your team avoid "pie in the sky" thinking and keep your project grounded in reality. For example, what might seem like a simple task of creating a theme and converting your screens to a Web interface can be complicated by ancient code and lack of documentation. By taking the time to discuss your modernization goals, you can realistically set expectations for what is possible.

2) Hitting the Road Without a Map

Now that you've defined what you want to accomplish through modernizing your applications, how do you get there? This is where a project roadmap comes in.

A project roadmap ensures that you're not only staying focused on your goals, but that you have the resources and tools available to help you reach them. Let's say, for instance, your team wants to create mobile applications that run off your IBM i database. A roadmap will outline the steps you need to take to go from development to deployment within the timeframe you've allotted, and it should account for user testing and the evaluation of any third-party tools you bring on board to complete the project. Additionally, it should include plans for future development so that your present-day tools and code scale to meet those goals.

3) Ignoring the Needs of End Users

Making sure you have the buy-in of the people actually using the application(s) you're modernizing seems like a no-brainer. But you'd be surprised at the number of times I've spoken with customers who haven't included end users in the project plan.

Some of the most successful modernization projects I've worked on included a test group of end users at the ground level. These users gave feedback on what they liked/disliked about their current applications, and they offered insight on what they wanted in a modernized application. For example, one company wanted to make their sales applications more user-friendly to increase the number of sales reps who used it. The project team included a sample group of sales reps who provided feedback and performed testing throughout the beta phase of the project. The development team was able to launch the modernized application with confidence knowing that their "customers" (in this case, their company's sales department) would be satisfied.

4) Disregarding the Power of IBM i

One of the most surprising things I hear when working with customers on their modernization projects is that they think they don't have the skills or assets to take their applications from green-screen to Web browsers or mobile devices without a significant investment in non-IBM tools or talent. These companies have a "throw the baby out with the bathwater" mentality when it comes to IBM i application modernization. The perception that the "i" is an outdated platform is a battle that more developers than I care to admit have fought within their organization. (After all, how many folks do we see still calling the platform "AS/400" or "iSeries"?)

Here are the facts: RPG ILE is a modern language. IBM i is a modern platform. IBM and the International Technology Group released a couple of studies in 2012 that studied the risks and total cost of acquisition/ownership of IBM i for midsize and enterprise businesses, and unsurprisingly IBM i outperformed Oracle and Windows across the board for security and stability. Despite this, I know of far too many companies that opted to migrate away from, rather than modernize and protect their investment in, their IBM i. And most of them are still paying (in the millions of dollars) for that decision many years later!

So, how to you avoid this pitfall? Unfortunately, there's no simple answer. Often, the decision isn't up to the people actually developing on the platform but is in the hands of business and IT executives who may not be aware of just how capable the platform is of supporting modern applications. Your best option here is to perform due diligence and make the case for protecting years—even decades—of development by staying on the platform. It may be helpful to create a sample Web application using RPG or PHP code using a third-party solution (Proof of Concept). This not only demonstrates the ability of the IBM i platform to support modern applications, but also offers a lower-cost alternative to migration.

5) Choosing the Wrong Tools for the Job

So, let's say you've avoided pitfalls one through four. You've set your goals, created a roadmap, and created a focus group of business users to test and provide feedback. You've done your research and found that it's much more cost-effective to modernize IBM i applications than migrate off of the platform. Now it's time to choose the right tools for your modernization project—a major pitfall waiting to happen!

Time and again, I speak with companies that have already invested in application modernization tools that are languishing on a shelf somewhere or that delivered such sub-standard results that the company just went back to using the very green-screen applications they were trying modernize. This really isn't that surprising once you realize that a lot of third-party tools for IBM i application modernization weren't developed with IBM i developers in mind!

Some development tools available only do part of the job—"screen scraping" or Web enablement—but don't create rich applications that are independent of 5250's character-based protocol. This is an important distinction if you want to add dynamic capabilities, like data scrolling, to your applications. Other tools require you to utilize non-native languages like .NET and Java, or invest in Microsoft technologies in order to modernize. Either of these options may work just fine for your purposes, but that's usually not the case for most RPG developers with whom I've spoken.

Here are some tips for avoiding this common, and potentially expensive, pitfall. First and foremost, simply evaluate the tools you are considering for purchase. If the ISV you are considering doesn't offer a free and easily available trial download, that's a red flag!

Next, work with the vendor on a Proof of Concept. This can be a small project to produce a sample application. This is usually the best way to find out if the vendor's product meets your requirements, but it's also an excellent way to find out if the vendor is the type of company you can trust with your business, especially if professional services are required for your project.

It's also very important to discover if there are any hidden costs associated with the vendor's product. For instance, will you be required to purchase additional hardware, software, or services to use their product? Will you need to hire outside help with development because their solution requires expertise with .NET, Java, EXT JS, or mobile languages? Make sure to include these questions into the discovery phase of your vendor evaluation process.

Finally, find out if the vendor's solution is able to scale for future development. Just because you don't plan to develop mobile applications today doesn't mean you won't a year or two down the line. If the vendor's tools don't support your future development goals, you may complete your current project only to find yourself needing to repeat the process of evaluating modernization and development tools all over again!

Final Thoughts
If I've learned anything in my years of helping companies transform their 5250 green-screens into modern Web and mobile applications, it's that there is no "one-size-fits-all" approach to IBM i modernization. I've worked with companies that start out with a few small applications and scale up over time, those that modernize major business applications with thousands of screens right out of the gate, and everything in between. But all of these companies have benefitted by applying the best practices I've covered in this article.

By following these tips, you should be able to avoid costly difficulties and setbacks to your application modernization projects and smoothly transition to the modern applications your business deserves!