anchor.diff:  
   ===== Proposed practices
   
  -Paul Hammant recommends the following practices:
  +Paul Hammant recommends the following practices [2]:
   
   * 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
  +  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
  +* 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
  +  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
  +* 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.
  +  also miss. This is a risk for any "rewrite" though.
   
   ===== Related Patterns
   
  
positive.code: ==== [pattern]#Strangler Approach#
  
  ===== Intent
  
  
  ===== Description
  
  Rewriting an old system "big bang" is a risky endeavour. It is harder than you think (see "Big Bang Approach" in aim42).
  
  An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over
  several years until the old system is strangled. The most important reason to consider a strangler application over a
  cut-over rewrite is reduced risk (it might cost more to do a strangler, but that's the price of risk reduction) [2].
  
  [[figure-strangulation]]
  image::strangulation.jpg["strangulation", title="Strangler Applications (Paul Hammant)"]
  
  He discusses two ways of achieving the goal of moving from the (red) old system to the (blue) new system:
  1) with adding new features and 2) without adding new features. Deciding to go for the first strategy means that you can still keep your business happy, because you are still able to
  deliver new features. However, this approach will take longer than the second one.
  
  
  
  ===== Experiences
  
  * Paul Hammont reports the following positive http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/[case studies]
    ** Airline Booking System: the C++ application which was stable but hard to grow (and find developers) has been incrementally
       replaced by a Spring stack based application. A load balancer routed the requests to either the C++ or the Spring
       application. They introduced session store used by both systems (the C++ application needed to be adjusted for this).
  
negative.code: ===== 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
    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 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
    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].
  