Moving a Traditional Software Package to the Cloud

The goal of this project was to take a traditional software package and make it available in the Cloud using a Software as a Service model. I conceived of and led this project, which was launched in 2010. The project used a single tenant architecture, which minimized the development requirements. The bulk of the work was in establishing a relationship with a cloud vendor and learning their platform; then developing a business case, a marketing plan, a usage-based pricing model and associated tools, a support model, and sales training and support. One of the most challenging aspects of the project was convincing company executives to support a cloud offering.

The software package was a workflow platform used in the transaction print industry to manage the end to end printing process for items such as cell phone bills, bank statements, etc. These are data driven processes that require high speed, accuracy, and security. This was the first cloud offering in the transaction print industry. This offering generated a lot of customer interest. My team provided detailed pricing and solution designs for over 20 customers in a two year period. It was also well received by the press and analysts such as Gartner and IDC but was a commercial failure. This industry is a very conservative and was not ready to make the move to the Cloud. However, it was very successful as a learning experience.

Building a Demo and Training Platform in  the Cloud

This project, begun in 2014, was designed to provide a cloud demo and training platform for a suite of traditional, server-based software packages. Our company had several software packages which were sold by a field sales force. The traditional way for sales staff to demo a package or to learn it was to load the package on their laptop. This was, and is not, a scalable solution. We got to the point where sales staff had laptops with multiple partitions, max memory, and in some cases, multiple drives they would swap in depending on the demo. I know of one region where sales staff were carrying three different laptops in order to be able to demo all the packages.

I conceived of a cloud solution which would provide the capability for sales staff to access a Cloud virtual machine (VM) running only the package they were going to demo which would be dedicated for their use. Depending on the package, the demo would be accessed from the sales staff laptop using either a browser (most of the packages had a web server front end) or Remote Desktop.

This was accomplished by building a “gold image” for each software package. The sales staff accessed a portal which let them request that a VM be built for the required package ASAP or schedule it at some point in the future. It took less than 10 minutes to build a new VM, so the ASAP method was more widely used. Once a server was built, it would be in existence for three hours and accessible through the public internet. At the end of three hours the server and all associated resources (network, storage, IP addresses, etc) were deleted. The first iteration of the project was built using the Microsoft Azure “classic” platform. A second iteration followed when Resource Manager was released.

This service had a number of advantages over the “stuff my laptop full of software packages” model. These include:

  • Rock solid performance – the image used to build a VM was carefully configured and tested to ensure there were no issues, including conflicts with other packages, lack of CPU or memory, etc. Using a gold image also ensured that all of the necessary resources, test files, etc. were available.

  • Low cost – The cost per hour per VM was approximately $.70. The three hour time to live for any VM minimized the charges for idle resources.

  • Scalable – We used Azure Active Directory to manage user credentials and there was really no limit to the number of demo/training VMs that could be built since the builds where entirely independent. We did have to keep an eye on the caps that Azure places on the number of resources available in a subscription.

  • Maintainable – As the administrator, I worked with the product owners to add new images as new versions of a package were released. Since the images were independent of each other, it was possible to make multiple versions of a package available.

  • Secure – The gold image was never exposed to the sales staff or the internet. Each VM was built from a copy of the gold image and then deleted at the end of three hours. The public IP address being used was dynamically assigned from the Azure pool. In the very slim chance that a server was compromised, it was not a useful platform given the short time to live.


I was both the sponsor and project manager for this project as well as the overall Cloud administrator. I hired a third party firm to do the development while I supplied the detailed requirements. For the migration to Azure Resource Manager, I supplied much of the architecture and built numerous automation prototypes using Powershell.




Building a Classroom in the Cloud

Our organization had a training team which provided a variety of classroom-based training for software package releases and updates. Typical class size was 15-20 participants and training could range from ½ to three days. Prior to the introduction of this project, each class would begin with ensuring everyone had the software package and training files loaded on their laptop. This typically involved some delay to sort out issues and work with people who had not prepared for the class and did not have the required software loaded. Of course, this also introduced the possibility of configuration issues and other problems on any of the users’ laptops.

I took the experience we gained from the previous project and used the same gold image concept to build a set of VMs for a class. This ensured that everyone would be working in exactly the same environment and completely eliminate the dependence and associated problems of loading the software on each laptop. All they needed on their laptop was a supported browser and, in some cases, Remote Desktop.

The process I established was to work with the product and development teams to get a gold image build on the required VM (either Linux or Windows). The gold image would include the correct version and updates as well as files developed for the class. Once the gold image was built, which typically took several days due primarily to back and forth on what was required for the class, I would then use tools I had built in Azure with Powershell Runbooks and Workflows. I could take the gold image and build a set of classroom VMs in about 15 minutes. I was able to achieve this quick turnaround by using the Parallel option available in Azure Workflows. This allowed for the build of each VM to proceed in parallel. Using a standard Runbook would have take 60-90 minutes to build 20 VMs as each build would be processed serially. This quick turnaround was very handy in testing the gold image to ensure that it met the instructor’s requirements. It was not unusual to go through several iterations to get to where the gold image had everything in it that was required for the class.

These software packages were sold in multiple geographies and our training organization was responsible for delivering training overseas several times a year. In these cases Azure's  global footprint was very useful as we were easily able to deploy an entire classroom environment in a target location (i.e., Tokoyo, Paris, etc.). This gave the instructors a familiar set of resources that were accessible with very low latency and kept surprises to a minimum.

To ensure cost optimization, I used the Azure Schedule tool coupled with a Powershell Workflow to start and stop the VMs according to the class schedule. At the conclusion of the class, all of the VMs and associated resources were deleted. This was done to eliminate any security risks and to minimize VM sprawl. This project was extremely successful as it significantly reduced class startup overhead, gave the training team much more flexibility in building the class environment, and provided students with a thoroughly tested and properly configured learning environment.





Cloud Architect 

In 2016, my organization finally decided to get serious about investing in building a suite of cloud services. A team was assembled which consisted primarily of packaged software application architects and developers. I was assigned as the cloud architect. Most of the team had little to no experience with the Cloud and my job was to provide guidance and education to the team. Here is a list of the activities I performed:

  • General education on the state of the cloud and primary considerations for the project

  • Presented examples from other cloud projects I had worked on

  • Cost modeling based on service prototypes

  • High level CI/CD pipeline and network architecture which took into consideration the existence of a mature on-site development infrastructure

  • Staffing plan and job descriptions for key roles – this included an architecture lead, security SME, and operations lead

  • Process for selection of a cloud vendor – I was determined to remain neutral in this decision, but I pushed hard to keep the team focused on the major cloud vendors (eg, AWS, Azure and Google).

  • Given the team's lack of experience in cloud architecture, development, and operations, I recommended hiring consultants to support the project, this included CI/CD architecture, security, operations, and training on the selected cloud platform

  • Wrote RFPs, identified potential consultants, vetted consultants, provided contract language, and planned project launch workshop content and schedule


© 2019 by Arielle Ross for Front Range Cloud Consulting. Proudly created with