You’ve signed a contract with your favorite cloud provider, updated your entire data center with modern converged infrastructure solutions, and you’ve optimized your entire ecosystem to support mobility and new kinds of end-point technologies. You understand that to stay agile in today’s market, you have to design an environment that’s ready for virtualization and cloud.
Now that the task is done at the data center level, what about your applications?
In working with almost every industry vertical, it’s clear that data and applications continue to be very serious stopping points. And with the current boom in mid-market spend on virtualization and cloud technologies, even more organizations are running into application migration challenges. Those challenges can be very serious:
- Some apps can’t be virtualized.
- Some apps simply can’t be moved into a cloud ecosystem
- Some apps have critical legacy dependencies
- Some apps are challenged by compliance and security measures
So now what? You’ve spent all this money on infrastructure and cloud only to be bound by a critical app or two. This forces progressive architects to hold on to legacy gear or an older part of their environment, which is not an ideal scenario.
Here’s the good news: new technologies are enabling a very granular understanding of applications and their unique requirements. So, if you’re facing a serious application migration challenge, know that you can work through these issues to get to a better state.
Before we move on, there is one important point to remember: it is definitely possible to end up with an immobile application. It could be code; it could be hardware requirements; or integration with other systems. If that happens, deploying a new app or service might be the only way to go, and the initial investment cost might scare you. However, if you’re hoping for one last chance to hang on to that legacy app, do consider the cost. You will have to hold on to legacy gear. You’ll have to find people to spend time to support the app. You’ll need to potentially deprecate optimal systems to support this app. Most of all, you might actually be slowing down the business by holding on to an app only because “it still works.” Even scarier are the security implications around an old application. Know your options, know when and how to migrate, and make your decisions based on the best interests of the business in the long term.
With that said, let’s look at some ways you can work with challenging applications and some application migration options.
Understanding the Application DNA
Some vendors call them RAG reports: Red, Amber, Green. These types of reports help you understand the makeup of an application. If the report comes back ‘red,’ you know you have some serious application issues. This can be everything, from code to drivers. Or, it can even be the type of OS the app can run on. If the report comes back ‘amber,’ you know you can work with this app. You might need to make some minor policy changes, update a registry setting, or isolate a VM. But, the point here is that you can migrate or at least work with the application. If your report comes back ‘green,’ you know the app is agile and can move between cloud and virtualization ecosystems.
These types of reports and analysis allow you to granularly understand the DNA of your application. It’ll help with migration planning, seeing clear challenges, and where you can create optimizations. These types of assessments must be done to truly understand the entire makeup of your application environment.
What to Do With Mainframes?
I hear this question time and time again. The architecture is certainly aging, as are many of the people supporting the environment. Still, mainframe systems are absolutely critical to many businesses. Banking, financial services, manufacturing, pharmaceuticals, and a number of other industries use mainframe systems as core parts of their businesses.
The good news is that there is still a lot of development around mainframe architecture. Middleware makes it easier to make data even more agile, and cloud providers can actually be mainframe-friendly. For example, there are services out there which will take your IBM AS400 and let it live in the cloud. They’ll handle the software upgrades and patches, and you basically get a mainframe-as-a-service type of environment. Most of all, these providers can even handle EDI transactions and data integration. One of the bigger challenges is moving from an older codebase to one that’s more supported.
The reality is that you might have to make that decision sooner or later. The best advice here is don’t let it surprise you. Plan for this type of migration and be ready to support your organization.
Working Around Dependencies
This is a challenging one to get around. There are so many applications out there, and each can be very unique. Some have calls to legacy Java environments, while others are accessing an aging database. What do you do if it’s a custom app? This will be a multi-layered approach. If you have a legacy repository or database that’s being accessed, try to create a parallel deployment of that data on a new system. From there, work to point the application to the new architecture and create modifications to the app as needed. Once you break apart the application, you’ll be able to see what can be easily migrated into a cloud or virtual ecosystem and what can’t be.
Remember, dependencies can also be around networking gear or even distributed connections. In those cases, it’s important to understand the resources being utilized and where you can abstract the application. In some cases, the only way to move an app will be to decouple it from all existing and legacy resources. This can be a challenging but necessary part of the app migration process.
Getting Creative with Challenge Apps
Applications can be packaged, virtualized, installed directly into a virtual desktop, and even streamed. In some cases, a simple physical-to-virtual process will do the trick. Other times, you might have to do a clean installation on a VM. You may also have to install the application as a package with certain registry settings to make it work.
The point is you have options. First, understand the application and what will allow it to be most effective. Then, understand your cloud and virtualization delivery options and deploy accordingly.
Ripping Off the Band-Aid
Imagine the following. Your organization has an aging CRM tool. You’ve build add-ons into it, you’ve put in customizations, it helps run your business, and it’s the bulkiest and most fragmented piece of software you have. In fact, a new version of that on-premise software might even break some of the critical customizations you made yourself. And now you’re stuck with a CRM platform that’s customized for your business but cannot be upgraded and is non-agile. Now what?
Many organizations are using new solutions, such as Salesforce, to move these massive operations into the cloud. What about those customizations? There are partners who actually work with you to understand your code and move it into a respective cloud CRM-ready architecture. Then, they help you test in parallel and allow you to create user readiness programs. These types of parallel migrations are the least disruptive and help make the entire move a lot easier.
The pace of application development is absolutely staggering these days. We’re seeing cloud-based systems take over functions only large on-premise environments could do. CRM systems, call centers, and even Big Data processing can all be done within a cloud ecosystem. By working with challenging applications, you’re not only optimizing your data center, you’re also helping your business.
Don’t get discouraged. If you’re stuck with an app, work with cloud, data center, and virtualization partners who can help. There are truly fantastic ways to conduct parallel migrations, create user adoption, and even create new strategies for the business when it comes to working with new types of apps. Don’t get stuck with an old app; get creative!