The “quiet” cutover and the role of the Digital Project Manager

In my experience, when planning launches of large systems with public facing components including websites, apps and APIs, the most effective strategy for successful ‘old-to-new’ cutovers is to save as little as possible for launch day. I like to call this the “quiet” cutover, or more comically “Launch your website with a …snore…”! It’s not to say that launch day isn’t a busy day filled with carefully timed activities, excitement, communication to customers and stakeholders and investors on the “new age” you are heralding with your next big thing. But the best risk mitigation strategy is to save as few activities for launch day as possible. For example:

  1. DNS / GSLB cutover is preferable. Most architectures allow for DNS cutover methods that allow the team to “flip a switch” to route traffic from the old to the new on launch day. Code deployment, content entry and testing tasks can be done well in advance. If using classic DNS changes, hosts file spoofing allows you to “simulate” launch day to allow technical teams to test in advance. If using more advanced methods such as DNS aliasing or GSLB from cloud service providers such as Amazon or Google, those tools can achieve the same “flip a switch” effect.
  2. Testing activities should be complete well in advance of launch. Even in more advanced build and release cycles, testing must conclude before the launch begins, with enough time for remediation. In more iterative projects, this means iterative testing must plan to be complete for all sprints with enough slack between testing ending and launch activities beginning.
  3. Migrate transactional data at multiple points along the way. By operationalizing the transfer of deltas between old and new systems, the last migration before cutover should be a routine task. Adding in a small outage period between the last migration and cutover provides a window to direct visitors from the old to the new.

Launching websites, apps and APIs are just some of many defining technical enablers of digital business. These require newer approaches than those from traditional IT project management. The “Digital” Project Manager is managing an omni-channel project that connects businesses with customers wherever they are: on the web, on mobile devices or beyond. Digital business is the “convergence of people, business, and things that disrupts existing business models.” In the context of cutover, the Digital PM answers questions like:

  • “What are the Business / Revenue / SEO ramifications if public traffic is temporarily unable to access my websites during a cutover?”
  • “What other dependencies are there on the services I am cutting over” These had traditionally been internal system dependencies (e.g. Payroll system relies on HR system, etc), but increasing we are having to look outside to the public internet ecosystem to truly understand dependencies (e.g. Am I surfacing live inventory data that my downstream resellers rely on?)
  • “How will I communicate with my users that changes are coming, whether they are desktop, mobile or API consumers”?

As businesses continue to connect to their customers through new channels, digital project managers will continue to drive teams to enhance digital capabilities of brands and businesses.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.