In the old world, custom development was the name of the game. You’d have a combination of homegrown applications and applications purchased from a vendor, with integrations in between. In the case of a merger or acquisition, you’d have to integrate between one organization’s homegrown applications and another’s.
But then came the cloud, and with it a new world.
In the mid-2000s, early adopters of the cloud used it primarily for lower costs against infrastructure. By the 2010s, as cloud proliferated, the movement shifted to low-risk migrations. During this time, cloud-native startups emerged that could respond more rapidly both to industry changes and their customers, which resulted in more innovation.
Today, cloud migrations are all about business innovation. As a result, many large organizations need platform modernization.
Some triggers that it might be time for your organization to consider a move to the cloud include:
Faster delivery to enable new business
Urgent capcity needs
Security threats that need addressed
Lease renewal or software EOL
When we work with clients seeking cloud solutions, we start with an assessment, where we consider the organization’s readiness:
- Yep, we can move. Some applications may already leverage vendors that are entirely cloud-based.
- Yes, but… Here’s where departments have to align on migrations around hundreds or even thousands of applications in their data centers. What’s the best plan forward for each? Do they refactor? Do they lift-and-shift?
- Nope, never. Perhaps an application runs on the original version of Linux or is written off the mainframe, in which case it would need to be rewritten entirely.
- I don’t know The client will have to take an inventory of applications to determine which are cloud-ready, whether the others need to move and what the process will look like if so.
Our experience in working with clients moving to the cloud indicates that companies often choose a gradual approach to adopting cloud technology — an approach that generally takes one of two forms:
Building development/test environments in the cloud
Generally, an organization will step first into development tests to get their feet wet in the cloud environment and/or to begin building the knowledge they need to prepare for production environments running in the cloud.
Deploying to the cloud with ties to on-premise services
The idea of a cloud-free environment in 2019 is a myth. A source-code repository like GitHub is cloud-based, and many corporate vendors, like Salesforce, are entirely cloud-based. These sources would be very difficult to compete against using on-premise infrastructures.
Ultimately, the cloud can provide businesses more agility, innovation and adaptation at a lower price point, but there are at least four major considerations your organization has to make:
This considers a combination of deploying and running things in the cloud, any hybrid solutions and ongoing maintenance and support with employees.
Address concerns such as unauthorized data exposure and leaks, weak access controls, susceptibility to attacks and availability disruptions.
The roles, skillsets and processes of employees who normally handle hardware and datacenter implementations will change as you move into cloud.
These are the guardrails your organization establishes around the cloud. Here, you create an environment that is flexible enough to offer the benefits of the cloud (e.g. the burstability and elasticity to quickly provision a dev environment) while simultaneously locking down environments.
Wherever you are on the path, Daugherty Business Solutions can meet you — from assessment and roadmap to migration and application development. Drop us a line.