... is Customization Rewrite
Hardly a surprise here, as voted by Twitter users at the end of June in a public poll, customization rewrite is still the biggest issue when migrating to the cloud.
The other two contenders are Security and Adoption, each taking almost an equal chunk of votes.
Why Customization Rewrite?
Considering the business is already using some kind of the system, they're more likely wanting to match features to what they have right now to minimize adoption challenges and workflow changes.
One of the options is to purchase an existing solution which does 80% of the job and manage the remaining 20% through training and workflow changes. This can be tough for your users to swallow, which is why Adoption is another key contender in the poll.
Another option is to invest in the platform which does 60-80% of the job and extend the rest to what you need. This has it's own challenges: building functionality to specifications, manage platform changes and their impact on your custom functionality,
Migration, does it only mean on-premises customers?
No. Migration does not only mean migrating from on-premises servers to the cloud, although it's a large portion of migrations out there that present a challenge.
Primarily, the challenge comes from customers who are used to the application functionality and now feel as if they have to settle for a smaller sub set of features "because it's in the cloud".
What about new cloud customers?
The types of customers here are new businesses or businesses who want to take advantage of automation and migrating semi-manual processes such as Dropbox and Google Sheets to, say SharePoint Online or Dynamics 365
These customers are comparing features they had with a combination of platforms to a single platform they're getting now. What many providers are competing against are: price of the new solution and consumer like ease of use.
Take a look below at two different contact screens to compare usability. Naturally, underlying features between the two systems are different but reduced usability for more back-end features is not always an easy sell.
What to do?
Start with your users
Who are your users? This is a simple question but, really, who are your users? If you're aiming to satisfy a small group of directors with cost savings of moving to the cloud - that may not be the long term sustainable strategy; especially if migration will affect staff who uses the application every day or customers with various degrees of experience accessing your app. Once you truly know who your audience is - you can then determine their habits, levels of experience, demographic and ultimately how difficult is to mitigate adoption hurdles.
Assess your road map
Where are you with the process you're trying to automate?
A few years ago I was involved in a process update for a financial client. The goal was to get rid of paper forms in favor of electronic submissions. The problem was that regulatory requirement still required a "wet" (no eSignature) signature. However, the company knew that this regulation was going to be amended within a year. This level of road map awareness allowed the company to architect the solution to fulfill future changes of dynamic instead of just focusing on the now, thus creating obsolete architecture.
Select the solution and it's road map
My favorite guidance here is to chose one of the 6 R's (as per Stephen Orban's Cloud Migration Approaches):
- Retain the current solution - don't change anything. This will depend on how difficult user adoption is going to be and the road map of your process. Some things are better left alone until the dust settles. This is also applicable when there is no good match for the set of features you're trying to retain.
- Retire - drop the process. This is is fairly common for solutions where the process is dropping in popularity. It's really the next step after the "Retain" option.
- Rehost - simple enough, take your existing solution and shift it to the cloud, change nothing or almost nothing. The benefit here is that rehosting is a fairly simple approach and requires almost no coding, nor end user change management. In many cases your change management is IT only.
- Replatform - choose a new platform, determine gaps, build feature according to user specifications. This is fairly high touch. Your users may not know something is changing, since the interface may remain the same but the interface will run on a new platform. Budget for support skills and consultants.
- Replace - drop existing application and replace it with something else off-the-shelf. The off-she-shelf part is the key, because if that off-the-shelf has gaps and extensibility is not supported, you're running in the scenario where user complains are piling up but you can't do anything about it.
- Refactor - buy something/use what you have and refactor it to fit into the cloud model. This is a more expensive approach but you have the flexibility to adjust features and make your users happy. This isn't a trivial approach so invest in change management, training, and support. You also need to think about training your IT staff.
Don't forget that whichever approach you take or the combination of a few - you must consider your users, the roadmap of your organization and the product or platform you're investing in.
What approaches have worked for you in the past?