Replacing Heritage Applications with SaaS, Part Four

In the first three (One, Two, Three) Parts of my series on replacing heritage applications with Software as a Service (SaaS), I’ve explored the concerns and expectations of the user community.  This week, I’d like to address the concerns of the IT operations departments who support the heritage application, and would be called up on smooth the transition to SaaS.

Obviously, every IT organization is organized differently, and provides different kinds of support even for different applications within their portfolio.  However, it is incumbent on the practicing IT project manager to work with these teams identify who would provide the relevant services.  Some of the questions to ask might include:

  • Where is the heritage application installed?  Where is the data stored?  How is it backed up?  These are some of the basic questions to get started, and the answers will likely lead to other questions about what is “going away.”
  • Who manages application security?  Who manages access to the data, if different?  Understanding the current information security roles and responsibilities will help determine who will need to be involved in extracting, purging, and possibly converting current transactions and historical data records.
  • Is there a budget for annual vendor support of the heritage application?  Who manages that budget?  If the application is going away, so will this expense.  But someone will end up with the operational budget to pay for the new SaaS recurring fee.  And it probably won’t be the same department.
  • Who provides first and second-level user support for the heritage application?  What support, if any, will they be expected to provide for the SaaS application?  Will users be referred to the vendor for all support questions?  Or, only some?  What information will need to be added, retired, or otherwise updated in their knowledge base?  Don’t wait until the day before roll-out to include these folks in the conversation.
  • Since the SaaS application will require internet access for the users, who manages the firewalls and routers?  What is the process for “white-listing” a site, or opening ports?  These folks need time to review the connectivity requirements, so they can provide bandwidth from the internal network to the vendor’s URL.  They may also be able to close out some services no longer required, especially if the users are distributed across multiple locations.
  • Does the vendor support the browser(s) used across the enterprise?  This seems like an innocuous question, until you run into a SaaS application written to take advantage of some HTML5 features, and your organization is still on IE7 (probably due to the requirements of some heritage application).  If your organization has a “standard” browser, someone owns responsibility for maintaining that standard, and making exceptions.
  • Who is responsible for application quality assurance?  If you have an internal group tasked with establishing test scripts for all applications, they need to be involved, even if it is to provide a waiver for an application hosted by the vendor.

Note that this list of considerations is barely a “starter kit.”  Many organizations have outsourced parts of their IT operations, and changes to which applications are supported may require changes to contracts.  And many heritage applications have special circumstances or supporting software; for example, my company has several mainframe applications whose users require terminal emulation software, which would no longer be required if they were replaced.  Someone would need to know of any changes, so they could seal up that access and stop paying support for that emulation software.

Also note that not all SaaS vendors provide sufficiently comprehensive offerings; your IT operations folks may be called on to support some work-arounds.   One of our SaaS vendors provides a truly useless ad hoc reporting capability, so we allow several analysts to access their database server via a secure connection.  The complication was that they use MySQL, and our IT department doesn’t support MySQL in any way; we had to get special permission to install software that would allow the analysts to run their queries from their PC’s.

I’m pretty sure someone reading this can offer examples of other considerations, concerns, and roadblocks they’ve encountered on the way to converting weary users to shiny, new SaaS applications.  Please add a comment to this post and share your story!  And next week, I’ll address involving the purchasing and legal experts in contracting for Software as a Service.  See you then!

Part Five

This entry was posted in IT Management by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.