John Q. Todd

Sr. Business Consultant/Product Researcher

Total Resource Management (TRM), Inc. 

The honest answer to this question is: Maybe. If you are thinking that you can take your entire on-prem environment and drop it into a cloud instance, well you need to do a bit more thinking. Yes, any function that you are supporting now on-prem can run in the cloud, but it’s the interconnections between those functions that can be tricky. Moving to the cloud is a good time to evaluate the usefulness of each system and its relationship to others.

Start with your User’s experience

In the end, the feature/function and availability of the environment to your users will be no different or perhaps even better. If they are accessing the application suite via a browser and URL now, they will continue to do so perhaps with a different URL. If they are using mobile applications on a tablet, they will continue to do so, again pointing to a different URL. If they have to login, perform dual authentication steps, or connect to a VPN, they will most likely perform those same activities.

The bottom line for cloud solutions and the user experience is that the User really has no idea where the environment is hosted, and they should not have to care. Your goal is a seamless transition for your users.

What about what the servers provide?

A database server provides data and a place to store that data no matter where in the universe it is. Same is true for email servers, file servers, application servers, etc. Any physical server can move to be a virtual server out in the cloud with no change in feature/function.

Even the interconnections between the “cloud-based,” servers are/can be virtual. No longer do we need to get on our hands and knees to track a network cable in the server room. Now those connections are made with a few clicks of a mouse. Even if the servers are in different cloud providers, the virtual nature of the connections can make for much simpler administration. Yes, bandwidth and throughput between providers should be part of your analysis and architecture planning.

What about backup/recovery and disaster recovery?

This is an area where cloud solutions shine. Based upon your contract, you most likely do not care how this happens, only that it is happening. No more cases of tapes to hustle back and forth to the “off-site vault.” In a modern cloud-based and clustered environment, any issues at the host are simply not visible to the user community.

What about performing patches and upgrades?

No real difference. Yes, the regular tasks of patches and upgrades must be performed. The difference may be who does them. Depending upon your contract with the cloud provider, they may do some or all. However, there may be accommodation for you to do some or all as well. The permutations of this area are numerous, and you get to decide what works best for you. If you have a robust approach to testing

and proving out new releases of your enterprise applications, that same approach will apply to what you have out in the cloud.

But I must have access to the servers!

We hear you. The vision of being locked out of your own server room is not a pleasant one. Even not having remote desktop access to your beloved servers may cause you nightmares. But it doesn’t have to be that way, and perhaps not needing access at that level could be a blessing.

Depending on the contract you have with your cloud host, you may have similar administrative access to the servers that you do now. Starting and stopping services, pulling logs, etc. may be part of your hosting package. However, question yourself as to why you need that access. Are these actions really something you need to do daily, or would it be better if the cloud host took care of them?

“But so often I must fix things that users mess up and need to take care of them immediately!” Automation is a key part of any cloud host operation. It is a very easy task to develop scripts and even leverage the Application Program Interfaces (APIs) that most all servers/functions provide that can take care of such issues. In our experience, reverting Work Orders back from the CLOSE status when inadvertently put into that state, is an easy automation to setup.

We are very customized and unique in the universe.

Don’t confuse complex configuration with customization. In general, any sort of configuration you have done in your on-prem enterprise application suite will migrate to the cloud environment. In the case of tools such as IBM Maximo, accommodation has been made for this level of migration. What functions on-prem will also function out in the cloud.

However, if you have customized, aka, hacked the underlying product code, that is something you should look at. As you move to the cloud, you want to simplify the ongoing maintenance of the instance, and always having to remember your customizations can cause trouble. Step one is to question what the customization is for and if it is still needed. Perhaps a feature/function needed years ago is now simply available in the product or can easily be configured. Get out your customizations documentation and take a hard look. (You do have customization documentation, right?)

You said integrations are the tricky part. Tell me more.

Despite all the wonderfulness above, you may have in place integrations between servers (or services) that can be difficult to implement in the cloud. Perhaps there is a set of edge servers that simply must stay on prem at a site. The thought of setting up, maintaining, and paying for an open VPN connection between those servers and your new cloud environment makes your tummy rumble. This is a valid concern.

Careful analysis of all your integrations is necessary before making the move to the cloud. You may find that some are simply not needed. Or, even better, the feature/functions that you are needing from multiple servers/software can be consolidated into a single or much smaller set. Take the time to explore if you can leverage more the inherent feature/function of a single enterprise software suite vs. cherry picking from multiples.

Keep in mind too that interfaces can be established to be on-demand or run in a batch mode, so you do not need an open connection 24/7/365. Systems can perform data blasts that take only a few seconds to upload between systems, potentially dramatically reducing costs.

Wrap up

TRM has been hosting Maximo environments for many years for many different types of clients. While some have rather simple needs, others require rather sophisticated interconnections and operational processes. Our Maximo SaaS services are up to any challenges you may have moving your environment from on-prem to the cloud.