The latest insights from 50 techies who love what they do.
In my last post I introduced the idea of Migration Resistant applications:
Migration Resistant applications are legacy applications currently hosted on dedicated in-house or private data center servers that have one or more attributes that make them difficult to migrate to the cloud. These are the applications that are always dropping to the bottom of the list when prioritizing applications to be moved to the cloud.
As I suggested in the first post some moves are so complex that they require expert assistance like a specialized piano mover to safely transport a grand piano. While applications with the following characteristics will benefit from expert assistance in migrating to the cloud, there are preparatory steps that should be started in-house and/or explicitly budgeted for when engaging an outside expert.
In this post I examine more deeply five attributes of Migration Resistant applications that are focused on technical complexity and various forms of “technical debt”
Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. More at Wikipedia.
#1 Customizations to a Third-Party Application - Your third-party application (ERP, CRM, Financial) has so many customizations that it is barely recognizable as the original licensed application.
Businesses often purchase standard third-party applications with good intentions to stick close to the industry standard processes it supports. Over the years complex realities of business evolve leading many organizations to write custom extensions and bolt-ons. Each custom module, feature, data structure and extension creates an additional failure point in migration to the cloud.
Heavily customized third-party applications are almost always frozen at an earlier version of the core application in order to avoid refactoring the customizations with each major upgrade. Migration to the cloud brings to the forefront the issue of porting old versions versus upgrading.
If your application is heavily laden with custom modifications, consider these steps to help prepare your organization to migrate this kind of application:
#2 Minimally-Documented Custom Application - Your custom application is uniquely suited to your organizational needs but it has been built up in layers over many years and documentation hasn’t kept up. Hidden/undocumented features, integrations, data flows, reports and dependencies make you reluctant to migrate.
Minimally-documented incremental development leaves current developers afraid to modify functions and variables because an undocumented portion of the code might depend on that function.
Here are three actions you can take to mitigate the risk of moving a minimally-documented custom application:
#3 Data Structure Complexity - Your databases contain hundreds, even thousands of tables and include many constraints, operational triggers, stored procedures and ETL processes embedded in the database layer.
Applications that rely on complex data models with hundreds or even thousands of tables are daunting to consider migrating. Migrating to the cloud also offers a prime opportunity to evaluate your organization’s historical choice of database vendor. Some organizations are switching to open source database engines when they move to the cloud rather than continue with a proprietary database engine.
The task of migrating an application with complex data models isn’t driven just by the number of tables. The migration takes on additional complexity when your enterprise application has embedded many business rules and logic into the database layer in the form of constraints, triggers, stored procedures and ETL processes.
Three actions to consider when preparing to migrate an application high in data structure complexity:
#4 Dependency Rot - Your application is dependent on old versions of languages, libraries and frameworks, some of which are no longer supported by a vendor.
Applications are built using programming languages, code libraries and frameworks. Those software components each have a life-cycle of their own. They evolve, introducing new functions and features, going through multiple releases sometimes stretching over a couple of decades. And, sometimes they fade from popularity so deeply that vendor support disappears.
Each time a component on which your application is built goes through a version release, upgrade or even just a patch, your organization is faced with a choice. Oftentimes the value of a new version is outweighed by the disruption and risk and so organizations stay with an older version of a software language or framework.
Repeated decisions to not upgrade leads to “dependency rot.” Many or even most of the components that your application depends on are now unsupported.
Migrating an application with many unsupported components from a stable dedicated server under your complete control to a cloud provider where hardware, BIOS, drivers and other low-level system settings may not be under your control creates multiple new points of failure.
Three actions to address dependency rot and get ready to migrate to the cloud:
#5 Tightly Coupled Integrations - Your application has multiple tightly coupled integrations with other applications.
To the degree that your enterprise application is tightly coupled with other custom or third-party applications that also run on your own dedicated servers, you understand that migrating that application to the cloud will carry an additional level of complexity in network, security and access control.
Four actions you need to make in preparation for migration:
These five attributes of Migration Resistant application each contribute uniquely to technical debt.
Paying down or paying off technical debt is an important part of of getting an application ready for migration to the cloud. Make sure your budget includes room for these preparatory actions, not just the move itself.
In my next post I will examine three attributes of corporate and regulatory complexity which also create resistance to migrating your enterprise applications to the cloud.