Gartner TIME methodology for app rationalization: Migrate

Gartner TIME methodology for app rationalization Migrate

The Gartner TIME methodology is a best-practice framework for determining when you need to migrate to a different application to better fulfill a business need. Let's consider what TIME says about when you should migrate your users to a new application.

The Gartner TIME framework is the standard method for application rationalization. It empowers enterprise architects to group the applications in their portfolio by the required action to rationalize them.

The TIME framework marks each application according to four possible strategies for dealing with it:

The previous two parts of this series of blogs have explored the first two options. Some of your applications will be tolerated to remain in their current state, and others will be worthy of additional investment.

In this part, however, we'll look at the third step: Migrate. This third category provides a strategy for replacing applications that aren't supporting your business needs to the level that you need them to.

Before you can categorize any of your applications according to the Gartner TIME methodology, however, you will need to gain a detailed overview of each application in your portfolio. If you need support with this, learn about how the LeanIX enterprise architecture management (EAM) platform can support you on our application rationalization page:

USE CASE: Application Portfolio Assessment & Application Rationalization

In the meantime, let's recap the TIME methodology before we explore Migrate specifically.

A Quick Reminder Of Gartner's TIME Methodology

As we explained previously, the Gartner TIME methodology assesses your applications for both technical and functional fit to your business.

In the model, technical fit refers to applications that have, for example:

high service levels
low risk
full integration with your tech stack

On the other hand, functional fit relates to how the application maps to your business needs. To help with mapping your applications to your business capabilities, we created our free template for business capability mapping:

Poster with the Best Practice to Define Business Capability Maps

By ranking each application against technical and functional fit on a matrix, you can find each within one of four quadrants:

Applications with high technical fit, but low functional fit will be Tolerated
Applications with high technical fit and high functional fit will be Invested in
Applications with low technical fit and high functional fit will be Migrated
Applications with low technical fit and low functional fit will be Eliminated

Each of these then offers a full strategy for dealing with them, as follows:

- Tolerate - accept the application in its current state for the time being
- Invest - prioritize in gaining maximum value from this application
- Migrate - work on finding a better application to fulfill this need
- Eliminate - remove the application as it is not needed or desirable

To put it another way, take a look at our flow chart from our Application Rationalization Playbook:

Gartners TIME framework flow chart decision tree

This forms the acronym: TIME. However, the acronym has a further meaning, in that you need to look forward to repeat your matrix for the next quarter, next year, and so on. This, of course, isn't as simple as it seems.

Let's look deeper at how you can make the decision about which applications to replace and which to keep. First, however, let's address the elephant in the room...

Does Migrate Mean Cloud?

If you do a quick Google search for Migrate under the Gartner TIME methodology, you'll immediately find some diversity of thought. Some commentators will define Migrate as we have here: replacing applications with low technical fit and high function with best-of-breed applications with high technical and functional fit.

However, more-recent articles seem to exclusively talk about cloud migration as application modernization when mentioning Migrate. Technically, this is only part of what Migrate means, but practically, this is almost always the case.

Modern cloud applications:

will be supported for a longer period of time
tend to be more open-source
often have simpler to use interfaces and may offer no-code solutions
are made up of micro-services
will generally be hosted in an affordable way

As such, as soon as you start looking at replacing a low technical fit application with a best-of-breed solution, you would almost always look at application modernization and cloud migration. Yet, that's a trend, rather than a universal solution.

You could imagine a situation where your organization is overspending on security to protect private data that's stored on a cloud service. In this case, it may be cost-effective to migrate that data into an on-premise service where protecting it is easier.

Of course, in 99% of cases, you'll be looking to transfer your Migrate applications to the cloud. It is worth, however, keeping an open mind to other solutions.

Which Applications Should You Migrate?

When considering the Migrate option under the Gartner TIME methodology, it's important to remember that marking an application as Migrate does not mean you will dispose of it immediately. The Migrate status is merely the trigger for planning to transition to a replacement application.

This actually makes your decisions far simpler. You don't need to commit to an instant migration, you just need to mark the application to add to a roadmap.

Rather than consider all the possible ramifications and contingencies of a migration, TIME just has you think about the two factors mentioned previously:

Technical fit relates to the quality of the application. Perhaps the application is completely reliant on a technical expert or advanced training to use. Maybe it's slow and prone to outage, or doesn't function with another system, requiring manual data transfer; or it could have security vulnerabilities or bad data.

Functional fit is how well the application aligns to your business' needs and required capabilities. Essentially, the question is: does your business need to be able to do what this application does?

Put simply, when an application performs a necessary function for your business, but isn't doing a great job of it, you need a replacement. How do you define what qualifies as a good or bad job, however?

A crucial source of information will be the application's users. Survey them on the application to determine whether it fits their needs and ways of working. User frustration is a key sign that an app isn't meeting the necessary technical standards.

Cost Is Key Metric For Migrate Under Gartner TIME Methodology

The other key metric is simply cost. If an application is taking up more resource, costing more, and taking more effort to maintain than similar applications, it's a good sign for you to look for a more-affordable solution.

Manoj Bhardwaj, Principle Architect at Finastra recommends assigning a score according to a five-point scale for each point of a set of attributes:

Architecture alignment
Maintainability
Reliability
Vendor viability and support
Availability of technology skills
Security

The five-point scale is defined as:

Non-compliant and unacceptable
Non-compliant, but acceptable
Partially compliant with acceptable deviations
Aligned, but with insignificant deviations
Fully aligned with current architecture

The final, total score will be a good indication as to whether the application is aligned with your current architecture. The less aligned the application is, the more resource will need to be diverted to getting it working with your current tech stack, and the more it will cost in terms of person-hours.

Regardless of how you measure the functional fit of your applications, the goal of Migrate is to reduce your expense on an essential app that is taking more than its share of your resource.

So, you have your list of Migrate applications ready. Now what?

How Do You Treat Migrate Applications Under Gartner TIME Methodology?

If you've read our previous article in this series on the Tolerate category under the Gartner TIME methodology, you may find the below list familiar. This is because the way you treat your Migrate applications is very similar to Tolerate.

As we established, Migrate doesn't mean you immediately replace your applications. This means that Migrate is usually a 'hold' condition where you park applications until further action is needed. This means:

1. Restrict Investment Into Migrate Applications

If you expect to soon replace an application, there is no point in making any investment into it, even when there is a business case for doing so. Better to save those resources for the migration. On the other hand, this is still a high business-priority application, so service levels must still be maintained.

2. Mitigate Risk

Further, the application has been seen to have a low technical fit. This could mean it has security vulnerabilities and stability risks. Minimizing investment, you will still need to mitigate those risks.

3. Look For Alternatives

The goal for your Migrate applications is to find a best-of-breed replacement. This means spending some time researching the market, what your competitors use, and comparing prices. This may feel like extra work, but finding the right functional fit will cut down on your Migrate list in future.

4. Prepare For Migration

Once your application is marked for migration, you should immediately start preparation. It's important to communicate to users that the app has been marked for replacement and why. If the app is a poor technical fit, then you will likely find the decision is welcomed, but there could be some objection management involved.

Migrate As The Most Popular Part of Gartner TIME Methodology

Migration can be the part of the Gartner TIME methodology that is the most work. However, it is also the part of the process that will win the most support.

There could, of course, be some objections to the changeover related to retraining and a degree of change management involved. However, the lack of technical fit to the Migrate applications should prove a clear need for the move.

Often, replacing a critical, but underperforming application will raise cheers among users, and win goodwill for the application rationalization process.

In the final part of this series, we'll consider what to do with applications that are simply no longer needed. In the meantime, find out more about how the LeanIX platform supports your application rationalization efforts in the Gartner TIME methodology: