What I Wish I’d Known Before … Implementing a Vendor’s Cloud-Based System

You still have to work at the application’s care and feeding – you can’t just “dump it in the cloud” and expect all the problems to go away. Some of them will, but not as many as you think.

The Internet gets slow and breaks more often than you think, especially when vital services are at the other end. Downtime procedures are even more important.

Do the research to figure out what all the pieces you will or might need are. Once you’ve done the big deal, you have very little pricing leverage until you have big money to commit again. Example: a full-copy test environment. With one well-known CRM vendor, those environments are priced as a percentage of total licensed product. That makes sense in a way, because a full copy is just that — a full copy. However, that also means that the cost of the environment goes up when you add more products or add-ons to your list of licensed things.

They seem to track their application only up to the point where it leaves their data center or Cloud Source. Anything else between their address and my user location is left up to me to figure out if there is a problem with the application and my users. We have had to go to other third-party products to get the health of the Internet between the SaaS source and our end users. Yet they (the SaaS source) blame our internal network setup for any end response issues at play. Very tired of hearing “none of our other users are having that problem” when the problem lies in the health of the general Internet and not our last mile.

Was the solution architecture design for the Web and cloud, or was it client-server front-ended by Citrix?

If it’s your first time down this path, your internal HIPAA team or legal may end up having no idea what to do with it based on their standard vetting process. You might have to take additional time in the implementation for back and forth with the vendor to while they jump through whatever hoops are placed in the way to get a green light to implement or even sign a contract.

I’ll have to pay to get my data back.

The importance of not just a DR plan, but a business continuity plan. You are not in control of when down applications will be available, but you still have patients to care for and business functions that must continue. Always have a plan and have it readily available for staff.

You won’t necessarily have full access to the database or software maintenance tools. Ask in advance and put a plan in place on how when data will be accessed / software changes will be completed.

You will spend a lot of time explaining your business operations. Analysts go from those making configuration changes to someone who needs to partner and fully understand business processes and operations. Vendors will not successfully function as your systems analysts.

This was 15 years ago. I wish we had known the true cost of going to the cloud. Verizon charged us a ton to install a redundant pathway to the Internet after questioning why we wanted to do such a silly thing.

Wish I’d required more detail in how my data will be turned over to me at contract termination. Our outgoing ambulatory EMR vendor refuses to hand over our contractually mandated export until the day *after* our account is turned off, giving us zero opportunity for smooth migration to the new vendor.

I wish we better understood and negotiated standard maintenance windows and patch load times for production issues. We sometimes have to wait weeks for patches and get a nine-hour window, any time during which the system could be brought down to install the patch. I also wish we had better prepared ourselves for the challenges of offshore support. They only want to talk via the ticket system and you have to try hard to get them on the phone or a WebEx. It really exposed now poor our internal support was since every issue required going through this painful process with the vendor support.