<blockquote>
  <p>... by making a minor change in the v1 front half, this breakage can be avoided.</p>
</blockquote>

<p>The above excerpt of this queston reminds me of something similar from around the late 90s, say 1996-1999 (when zillions of ITers were preparing for Y2K ...). In those days, new software releases of huge software vendors would come with release notes that included things like either of these:</p>

<ul>
<li><em>"this release is to make this software <strong>Y2K tolerant</strong> "</em> (= allows the software to contnue to work as of Jan 1, 2000, at least for a while, though it would keep showing dates with 2 digits for the year, like 00, and not yet 4 digits, like 2000).</li>
<li><em>"this release is to make this software <strong>Y2K ready</strong> "</em> (= allows the software to continue to work as of Jan 1, 2000, without any (known) limitation because of the change of century from 19 to 20).</li>
</ul>

<p>Y2K tolerant softwares would typically also include some sort of magical cut-off value, e.g.: years from 70 (when even MS DOS did not exist ...) to 99 were assumed to be from 1970 to 1999, while anything from 00 to 69 were assumed to be from 2000 to 2069. Such assumption was also why such softwares were required to be superseeded by some Y2K compliant release later on (in which those assumptions were obsoleted).</p>

<p>With the above in mind, the term you are asking for could be something like a "<strong><em>V2 tolerant release</em></strong>", which at some point in the future would then be followed by a "<strong><em>V2 ready release</em></strong>" (= your actual V2 release).</p>

CC BY-SA 4.0
2019-11-01T14:11:18.863Z
2019-11-01T14:11:18.863Z
Pierre.Vriens
<p>"Compatibility layer" sounds good to me.</p>

CC BY-SA 4.0
2018-05-10T21:34:28.827Z
2018-05-10T21:34:28.827Z
AnoE
<p>Perhaps "Zero-downtime live migration"</p>

CC BY-SA 4.0
2018-06-10T15:25:25.470Z
2018-06-10T15:25:25.470Z
James Shewey
<p>I'm currently working on a new major version (v2) of an application meant to replace the current production version (v1). This redesign carries with it changes to the front-end, public API layer, internal API layer, and database — the whole kit and kaboodle.</p>

<p>While it is easy to have active v1 and v2 front-ends and public API (which I'll call the "front half" for brevity's sake) simultaneously in our lower environments, for various reason, this is NOT possible for us to do with the internal API and database (which I'll call the "back half").</p>

<p><a href="https://i.sstatic.net/u5DLs.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/u5DLs.png" alt="enter image description here"></a></p>

<p>The v2 redesign necessitates changes to the back half that cause breakage in the v1 front half. However, in this particular instance, by making a minor change in the v1 front half, this breakage can be avoided. As such, it is possible for us to deploy this v1 "shim" along with the changes to the back half to production. When the time comes, we will be able to cut over to the v2 front half without the back half needing any further deployments.</p>

<p>Is there a name for this particular type of deployment, where a shim is deployed to an existing app to make it work with an updated back end, with the goal of making a future cutover seamless?</p>

<p>Taking my definition of blue/green deployment from <a href="https://minops.com/blog/2015/02/the-dos-and-donts-of-bluegreen-deployment/" rel="nofollow noreferrer">this informative blog post</a>, I believe this is a distinctly separate kind of deployment.</p>

<deployment><terminology><release-management>
What is the term for a deployment designed to make a future cutover seamless?
Jacob Stamm
# What is the term for a deployment designed to make a future cutover seamless?

(Asked by: username_0 on 2018-05-10)

I'm currently working on a new major version (v2) of an application meant to replace the current production version (v1). This redesign carries with it changes to the front-end, public API layer, internal API layer, and database — the whole kit and kaboodle.

While it is easy to have active v1 and v2 front-ends and public API (which I'll call the "front half" for brevity's sake) simultaneously in our lower environments, for various reason, this is NOT possible for us to do with the internal API and database (which I'll call the "back half").

[![enter image description here](https://i.sstatic.net/u5DLs.png)](https://i.sstatic.net/u5DLs.png)

The v2 redesign necessitates changes to the back half that cause breakage in the v1 front half. However, in this particular instance, by making a minor change in the v1 front half, this breakage can be avoided. As such, it is possible for us to deploy this v1 "shim" along with the changes to the back half to production. When the time comes, we will be able to cut over to the v2 front half without the back half needing any further deployments.

Is there a name for this particular type of deployment, where a shim is deployed to an existing app to make it work with an updated back end, with the goal of making a future cutover seamless?

Taking my definition of blue/green deployment from [this informative blog post](https://minops.com/blog/2015/02/the-dos-and-donts-of-bluegreen-deployment/), I believe this is a distinctly separate kind of deployment.

**Tags:** deployment, terminology, release-management


---

## 3 answers

### Answer by username_1 on 2019-11-01. Score: 2

> ... by making a minor change in the v1 front half, this breakage can be avoided.

The above excerpt of this queston reminds me of something similar from around the late 90s, say 1996-1999 (when zillions of ITers were preparing for Y2K ...). In those days, new software releases of huge software vendors would come with release notes that included things like either of these:

* *"this release is to make this software **Y2K tolerant** "* (= allows the software to contnue to work as of Jan 1, 2000, at least for a while, though it would keep showing dates with 2 digits for the year, like 00, and not yet 4 digits, like 2000).
* *"this release is to make this software **Y2K ready** "* (= allows the software to continue to work as of Jan 1, 2000, without any (known) limitation because of the change of century from 19 to 20).

Y2K tolerant softwares would typically also include some sort of magical cut-off value, e.g.: years from 70 (when even MS DOS did not exist ...) to 99 were assumed to be from 1970 to 1999, while anything from 00 to 69 were assumed to be from 2000 to 2069. Such assumption was also why such softwares were required to be superseeded by some Y2K compliant release later on (in which those assumptions were obsoleted).

With the above in mind, the term you are asking for could be something like a "***V2 tolerant release***", which at some point in the future would then be followed by a "***V2 ready release***" (= your actual V2 release).


---

### Answer by username_2 on 2018-05-10. Score: -2

"Compatibility layer" sounds good to me.


---

### Answer by username_3 on 2018-06-10. Score: -2

Perhaps "Zero-downtime live migration"


---

