We've found both as authors of this weekly blog and also as readers of other blogs that while academic, theoretical advice on software issues is terrific, nothing beats real-world examples.

Even better than specific samples of code, the most instructive stories we can share are case studies.

With that in mind, we'd like to share a specific few months of processes we had to transition a software product from one company and their server space to the new purchasing owner's company's server space.


The Scenario

Years ago, we were brought in to improve and maintain a complex app for factory maintenance software. It was a tougher job than one might imagine - there were some bug fixes and new code definitely needed for years on the software. But the company that brought us in was in a tough predicament of knowing time and money really should be put into code upgrades, but the revenue at the time couldn't have justified that effort. We maintained the product successfully, making hopefully smart and tough decisions along the way.

In late 2020, a new company stepped in to buy the software, the code, and the client service contracts from the original company. Everybody involved agreed that it was best for us (Plannedscape) to continue to maintain and develop the software.

Our primary task was to migrate everything about the product, including the server and ownership, from the original company to the new owners.

That may sound fairly easy, just switching a server. Thinking that way can come back to bite you. Here's our case study from the transition.


Planning Meeting

Shortly after the software sale we met with the new owners for a planning meeting.

Admin - We had some red tape to work out with them, such as our work agreement, purchase orders. But we quickly figured out a team of two key people on their side and two people on our side to be critical point persons on the project.

Azure Hosted -We had been hosting the software on Microsoft Azure and everyone agreed that we could ease the immediate transition by keeping it there. We gave instructions for the new company to start their Azure account and get us the necessary DNS information.

New URL/Server - The product definitely needed to move to a new home and URL under the new company's web domain.

Planned Migration Date - We set a date for three weeks in the future. We wanted to move quickly, but not unreasonably so where there would be a difficult transition. All clients needed to continue using the online software app with no interruption. A few of the large customers had 30-40 employees doing pretty much all of their daily work in the app, so any outage or hiccups would be costly.


Last Pre-Migration Meeting

We had another meeting among the four principal point people on the project the Monday before our Friday cutover.

Scheduled Transition Time - We had been announcing a planned outage of the software over a weekend, Friday 6pm EST through Sunday 6pm EST. We had that luxury of a 48-hour downtime since all clients are corporate and working on a weekend would be a rarity in that industry. For more B2C products, you won't be able to have such an acceptable long downtime period.

Friday Date - By the way, we heartily recommend a Friday afternoon cutover for any server changes. We have all of our hands on deck in office hours to make the switch. But if something goes wrong, then we could conceivably scramble over the weekend to restore order.

Azure Ownership - We scheduled the ownership change to be that Friday on the account; we arranged that with both the previous and new owners. It only seemed fair. Since they were cooperating this made the switch a little easier. Although we could have had them with separate accounts. We found this removed one layer of potential problems, so we pushed for it.

Warnings To Existing Users - We gathered company contact info from previous company for the new owners to contact them with a message about new ownership, and a new URL for the software location for all users. (We also made it so users could still go to the old address and be properly forwarded for a few weeks; we made that a part of the sale that the previous owners would keep their URL up for us to have those forwarders after the server switch.)

Code Changes For Domain References - We were to review code to ensure that any literal references to literal domains existed in code. For instance, if the code referenced www.oldcompany.com/config.cfg then things would break. Yes, that's bad policy for any codebase but again, we did not originally write the app, and we wanted to do our due diligence.

New Login Message - In advance, we planned to modify the login pages for all clients to be aware of new support address and highlight new Fusion URL (and tell them that previous domain forwarding will end soon, they need to make new bookmarks).


Migration Day

Everybody involved had open schedules to prepare for the worst yet plan for the best. It turns out, we had an extremely smooth transition.

Our Biggest Problem - There was a flaw in our forwarding concept. The DNS/domain forwarding sitewide could only forward to ONE url. The previous deployment unfortunately had a client-dependent URL. The longtime previous company schema was to have folders for each client (yucch), like oldproduct.com/client/NewLogin.aspx or oldproduct.com/otherclient/NewLogin.aspx etc.

Some of the clients reported problems, which were just a matter of not getting forwarded. We quickly (Brad at Plannedscape) removed the domain forwarding, so if people that day and that weekend went to www.olddomain.com/client/NewLogin.aspx then that's where they would stay. Which is good.

Both the oldhost.com and newhost.com domains were pointing to our Azure server and to each client's correct database. So there was no problem for the moment leaving both domain active, but we should address this together on Monday.

I changed the code to be forwarded via code and deployed that on Saturday where I could reliably test in a calmer way, with a staging site and staying away from the nightmare of live fixes.

Otherwise - Everything else was smooth. Code worked in new environment (which we tested extensively in a staging server). Communication and messaging to users was great.


Post-Migration

We had a solid meeting in the week after the transition.

Users - We had been logging forwards and by the end of the week found that users had all transitioned to using the correct, new URL.

Help Desk - We established a project management / QA site to track user-reported issues. Was very well received.

Source Code - While we do not expect everyone in the transition team to personally be deploying new builds of the .DLL, we wanted standard source control for the code. We gave BitBucket access for the code & make sure the repository is up to date

DB Access - There were and are several members of both our side and the new ownership's side who are capable of making database-level changes to the product. A few sections of the product logic is in stored procedures, meaning changes can be effected without going into "source code".

Next Steps - We had been postponing some much-needed improvements until after the server transition. So, this was the time to discuss. We had an SQL version upgrade needed - and we had already informed them of this pre-sale and incorporated the necessary ours into our original work plan and budget estimate.

We also had a triaged list of planned code improvements and documentation plans ready to go.


Keys To Success

There wasn't anything particularly innovative about our approach to the transition. We just were thorough enough to discuss potential issues with four pretty intelligent and reasonable people in video conference sessions to come up with best approaches.

Key #2 sounds a little pessimistic about people in general, but I love that we only had 4 people discussing things. Had there been committees of 10 or meetings where 8 people had to ask endless questions to understand some of the basics, the transition would have been a lot slower. A small, nimble and skilled team makes things very easy.

But the real factor for the transition success was a client that absolutely understood the need for allotting a proper amount of time.

A new owner of a software product could have easily insisted that they bought it on a Tuesday and servers should be switched that Wednesday. In our opinion, that's a recipe for disaster. We were blessed to work with point people and new company management that understood the "measure twice, cut once" approach towards doing things right.