anchor.diff:  ===== Risks
   
   * You need to overcome the lack of will to actually finish the strangling (usually political will from
  -  non-technical stakeholders, manifested as lack of budget). If you don't completely kill off the old system, you'll
  +  non-technical stakeholders manifested as lack of budget). If you don't completely kill off the old system, you'll
     end up in a worse mess because your system now has two ways of doing everything with an awkward interface between the
     two. Later, another wave of developers will probably decide to strangle what's there, writing yet another strangler
     application, and again a lack of will might leave the system in an even worse state, with three ways of doing things [1].
   * You need to have consensus across the development team(s) on the future state of the architecture and how to get there.
  -  If everyone runs into another direction, then you end up with a new system, which is also hard to maintain.
  +  If everyone runs in another direction, then you end up with a new system, which is also hard to maintain.
   * If you're introducing technologies that are new to the team or to support/maintenance staff (e.g. adding reliable async
     messaging to what is currently a synchronous three-tier client/server architecture) then you have to ensure that there
  -  are experienced technical leads on the project who know how to build systems with that technology, and support those
  +  are experienced technical leads on the project who know how to build systems with that technology and support those
     systems. And those tech leads have to stick with the project for some time after the old app has been fully strangled.
     Otherwise, the architecture will degrade as inexperienced developers modify it in ways they know but not in ways that
     fit with the new architecture [1].
  
positive.code: 
  ===== Proposed practices
  
  Paul Hammant recommends the following practices:
  
  * You really should phase the strangulation. Keep your larger application in a continually deployable state while working on it.
    The first go live after a month or so of work, then every two weeks after that at least or you’ll fail. That would
    probably via project cancellation by a checkbook-holding sponsor.
  * Do enhancements or new “business value” work concurrently with strangulation, while getting all to agree that both are
    happening. As you work on the strangulation, a decent percentage of work should be enhancements too. This allows value
    to be associated with each release from the point of view of the people paying for it. ROI and all that, isn’t just
    abandonment of costly end-of-life IT choices, it is about tangible changes for the better. From top to bottom, everyone
    needs to agree that both are happening.
  * The additional of integration and functional test suites as a safety net is key. This is particularly true for when the
    old technology did not have unit test coverage. The functional tests will be able to step between old and new (and back),
    to prevent surprises.
  * Understand that Non-Functional Requirements (NFRs) that don’t directly cheapen the re-implementation may jeopardize the
    initiative. Jeopardize in the “courting cancellation” territory again. Various authority figures may have pet technologies
    to include, or things to exclude. The test is whether the dev team cranking stuff out agrees or not.
  * Agile methodologies optimize everything for maximized developer throughput, and phased deliveries to production. You
    will not manage this with waterfall, unless you want glacially long intervals between production pushes.
    The http://cdn.pols.co.uk/papers/agile-approach-to-legacy-systems.pdf[Pols/Stevenson white paper] drills much further into the Agile aspects.
  * Lastly, you should always be aware that there could be functionality and context hidden within the old application
    that people have forgotten about, and that a team of business analysts assigned to reverse engineering behaviors might
    also miss. This is a risk for any “rewrite” though.
  
  ===== Related Patterns
  
  
negative.code:      new (Swing-based) client. The users weren't forced to use one or the other, but the team made the new application
       so compelling that they wanted to. Google is (as I heard from a Googler) doing similar approaches to their internal
       systems, which are replaced by new systems all the time and you need to decide when to switch.
    ** National Supermarket's internal planning system based on Swing and a major database is moving into a Rails and Java
       Microservices based web application. Since the two technologies are also very different, there is no smooth way of
       integrating the old and the new system, they have to exist in parallel (it is an internal system)
    ** Used consumer goods magazine's web portal - a move from Oracle Endeca to Java/JavaScript. First, they changed the
       Oracle frontend that it looks like the new system. Then they integrated a little piece of new functionality from
       the new stack into the website. The first strangler release took 6 months, then the delivered regularly.
  * Nat Pryce reports failed projects and challenges using the strangler pattern [3]:
    ** "I've seen critical systems that have suffered both of these fates, and ended up with about four or five
       "strategic architectural directions" and "future state architectures". One large multi-site project ended up with
       eight different new persistence mechanisms in its new architecture."
  