The most complicated part of any migration is the migration of complex custom applications. We discussed the migration of simple content in our previous post, but the history and variety of complex applications make them an entirely different beast. Most enterprises have at least a few complex custom apps; those apps are often built over the course of several years, and entwined deeply enough with the legacy deployment that the tactics used to migrate simple content aren’t successful.

Despite the potential problems they pose, most enterprises need continued access to their custom applications – if a legacy application has stayed in use this long, it’s likely fulfilling some critical function and can’t be easily replaced. They can be tricky to migrate, but there are ways to make it work. We’ll discuss some of the potential pitfalls and best practices in this post.

Migrating Complex Applications: Potential Pitfalls

Of course, the first thing to check is whether your migration partner can migrate the applications in question. While the ideal answer is yes, some applications are just too complex and deeply layered to move in one piece. Others are complicated enough that it’s not cost-effective to move the application over, and would instead be better to recreate the app in the new deployment.

There are a number of potential reasons why your enterprise might run into hang-ups with legacy app migration. Some of the common ones include unresolvable interdependencies on other legacy content/apps, making the migration process more of a group task than an individual migration, and some custom apps call on external services to retrieve data or accomplish tasks. Some systems are more likely to contain custom applications with external dependencies than other systems – for example, SharePoint sites often have external dependencies on Oracle databases or SAP applications – but in order to migrate an app successfully, these dependencies need to be resolved. Some complex applications are just so deeply rooted in their deployment, with years and years of data accumulated behind them and new features added over time, that moving all of it would be an extremely intricate, time-consuming task.

If an app relies on a specific piece of the legacy deployment that isn’t slated for migration, or a type of connection that the new deployment doesn’t support, it’s likely to be very difficult to migrate. Sometimes the person or people who created that app can help resolve these dependencies or find acceptable workarounds, but this approach often runs up against another problem: more and more enterprises are also dealing with situations where the original programmer or administrator of an app is no longer with the company.

This is increasingly a problem as workers proficient with some systems (such as IBM Lotus Notes) change companies or phase out of the work force. If there’s no one left on staff who has the depth of knowledge to explain the app at the level of understanding your migration partner needs, it’s going to be very difficult to migrate that app.

Another common problem is a mismatch between source and target system capabilities. Sometimes it’s as simple as the legacy source system having functionality that the target system doesn’t offer. This is increasingly common for enterprises still relying on IBM Lotus Notes, which had a variety of features that haven’t all translated cleanly into modern systems, but other systems can also offer challenges along these lines.

Migrating Complex Applications: Solutions and Best Practices

Fortunately, most migration partners are able to diagnose those problems ahead of time. The pool of migration partners that can help you avoid and overcome those pitfalls is somewhat smaller, but they’re out there as well. With an understanding of which of those issues may apply to your enterprise’s complex apps (which you should already have at least some insight into thanks to your assessment results), it becomes much easier to find solutions that will enable your apps to be migrated successfully.

In cases where your legacy app has been maintained because the functionality it relies on hasn’t been available or reliable in new deployments up until this point, there’s good news: many modern systems have capabilities that can replace or improve upon common functionality found in legacy apps, especially Notes apps. Ask your migration partner if they can recommend a supplementary system for any lingering functionality that hasn’t been replaced yet. Office 365 in particular offers a wide range of features and functions across its developing platform that can close any lingering gaps between features offered by first-generation and modern deployments, so sometimes it’s even possible to replace your custom legacy application with a combination of ready-made cloud solutions.

In cases where your enterprise is dealing with increasingly complex or particularly layered applications, it can be easier to look at the collected functions and features of the app and see if it can be recreated in the new deployment, or if your migration partner can build a functional replacement. Resolving external dependencies isn’t always easy, but in cases where your enterprise is keeping other parts of its current infrastructure (such as Oracle databases), it becomes much easier to move the app and hook it back into its external sources.

Cases where the legacy app and the external source it needs are both moved to a new deployment can be a little trickier, depending on which systems you’re moving to and which connectors your legacy app is built to work with, but in most cases it can be done. Of course, if your enterprise does decide to rebuild an app from scratch like this, and it’s not limited by drawing on externally stored data, be sure to see if you can scrape the data out of the old app and add it to the new one. That’s often easier than moving the entire structure of the app.

As always, we recommend you communicate with your migration partner – in this case to see if, first, they can migrate your complex legacy applications. If they can, great, that’s the simplest option in a relatively complex process. If they can’t fully migrate your complex custom apps, or can migrate some of them but not all of them, see if they can suggest target deployment substitutions or replacements for any parts they can’t migrate. Ongoing synchronization between the legacy deployment and the new deployment is also an option, if you only need a small portion of the infrastructure to maintain the application in question, though it isn’t ideal. If your migration partner declares that the application is just too detailed and complex to migrate, don’t despair – work with your migration partner to look for ways that the required functionality could be recreated in your enterprise’s new deployment. It’s also okay to start considering alternate migration partners if the one you’re currently working with isn’t able to address the app in question to your satisfaction.

Conclusion: Summary and Next Steps

Migrating complex custom applications is a daunting task (and the cause of most migration horror stories), but a proficient migration partner can get you through it. Enterprises are even sometimes pleasantly surprised by how simple it is to move a longstanding older application – hello, Lotus Notes! – into a modern cloud system. Since migrating complex applications is generally the final stage of a migration, the process of carrying out and cleaning up a complex application migration means that the end is in sight and your migration has almost succeeded.

The final step, confirming that the app has been migrated correctly, dovetails neatly with the process of confirming that the rest of your enterprise’s content and apps migrated correctly. Confirming that your legacy apps have been migrated successfully and confirming that your entire migration has been carried out correctly are, in effect, the same process but on different scales; we’ll discuss this process in the final post in our blog series. In the meantime, please feel free to contact us with any questions about this post or complex application migration.