As the average duration of outsourcing contracts continues to become shorter, the issue of exit grows in importance. By tradition, best practice in negotiating exit terms has been: plan it early, and work hard to make it uncontroversial.

Sometimes, a case comes along and helps to remind us why a pre-contract focus on exit is important. A recent UK case, AstraZeneca v IBM, reinforces the importance of addressing the termination and exit provisions of an IT services agreement at the time of signing, rather than when the time has come to exit that agreement.

BACKGROUND

The case arose out of a July 2007 Master Services Agreement (MSA) between IBM and global biopharmaceuticals company AstraZeneca for the provision of IT services. AstraZeneca terminated the MSA in April 2011, triggering (so AstraZeneca thought) various exit provisions, including an exit plan to bring the services back in-house or to transfer them to another provider. This gave rise to a dispute between the parties regarding the interpretation of those aspects of the MSA relating to IBM's provision of exit services.

The English High Court reviewed the meaning of various outsourcing termination assistance and exit obligations. The court's judgement is heavily centred upon judicial interpretation of the terms of the MSA, but nevertheless provides some useful guidance for the negotiation and drafting of IT outsourcing contracts. The task of the court was to ascertain the meaning which the MSA would convey to a reasonable person having all the background knowledge which would have reasonably been available to the parties in the situation which they were in at the time of the contract, but excluding their previous negotiations and declarations of subjective intent.

The court's judgment will probably provide more encouragement to customers than to service providers because, for example, it refused to limit artificially the bounds of IBM's multi-client environment which IBM would have to deploy to support AstraZeneca's exit, and it allowed AstraZeneca to dictate the rate and shape at which individual services would be transitioned away.

However, even though this was an English law case, the main lessons of this situation are universal:

  • Exit will generally always be a difficult time when emotions are likely to run high and the parties are clearly heading in different directions. The job of the Exit Schedule should be to remove controversy, not to fuel it.
  • Be very aware of how shared infrastructure (contracts, technology, personnel) can be split; understand the self-sufficiency plan.
  • It is amazingly common in the outsourcing industry for parties to agree in advance that an initially high-level exit plan will be turned into a detailed exit plan within a few months of contract signing – and then not to do so! This is a key trap to avoid.
  • Pay as much attention to defined terms in schedules and annexes as to defined terms in the main agreement.

SCOPE OF IBM'S EXIT OBLIGATIONS

One of the central issues in the case concerned IBM's obligations to provide services to AstraZeneca after AstraZeneca had terminated the MSA. IBM had to perform certain contractual obligations during the exit period, but was also obliged to provide "shared services" to AstraZeneca for up to 12 months after the end of the exit period. Shared services were services provided by IBM to AstraZeneca under the MSA which were shared with other customers of IBM. The MSA provided that, if requested by AstraZeneca, IBM would provide the shared services for up to 12 months after the end of the exit period, as any replacement supplier might experience difficulties taking on the provision of these shared services.

The MSA defined the concept of shared services by reference to "shared infrastructure", which was not defined in the MSA. The court found that the term "infrastructure" was used in the MSA to represent a variety of meanings, and held that the meaning of "shared infrastructure" ought to be determined in light of the overall context of the MSA. IBM sought to limit the services that it would need to provide to AstraZeneca during and after the exit period; the way in which shared infrastructure was construed was important in this context.

IBM submitted that the shared services were limited to situations where IT infrastructure, such as servers or software, was used by IBM for more than one customer. AstraZeneca claimed that shared services should be construed in a wider sense and included the underlying services to these infrastructure components, such as staff, physical and logical security, electricity supply and air conditioning required for the maintenance and effective use of data centres and server rooms. The court found that the definition of infrastructure had been used inconsistently in the MSA but was wide enough to include all the equipment, systems and facilities at IBM's data centres.

RAMP-DOWN

The court also had to consider whether AstraZeneca had a right to select which of the shared services it required IBM to continue to provide during the exit period. IBM submitted that AstraZeneca was not permitted to ramp down the services as AstraZeneca saw fit. The court decided that the exit plan contemplated by the MSA meant that, by the end of the exit period, those services which were being terminated were to be transitioned back to AstraZeneca or another supplier, and there was no reason why these services could not be transitioned on an individual basis. Accordingly, it was held that the terms of the MSA permitted AstraZeneca to select which services it wished IBM to continue to provide post-termination.

DURATION OF EXIT PERIOD

The court also ruled on the duration of IBM's obligations to provide exit assistance to AstraZeneca. AstraZeneca submitted that IBM was required to provide exit assistance until all responsibilities were transferred to AstraZeneca or a successor supplier, irrespective of the end of the exit period; whereas IBM claimed that it had no obligations after the expiry of the exit period (save in regard to the shared services which had not yet been transferred). The court held that, save for its obligation in respect of the shared services, IBM was not under any contractual obligation to provide services to AstraZeneca after the end of the exit period.

FIXED FEES?

The MSA provided that AstraZeneca would pay a fixed fee to IBM for termination assistance during the exit period, but the value of this fixed fee had been left blank when the MSA was executed. At trial, IBM submitted that it could not provide a valuation of the fee for the provision of exit services until AstraZeneca had submitted an IT transfer plan providing IBM with an indication of what AstraZeneca required to transition the services, and how long AstraZeneca expected such transition to take.

The court dismissed IBM's argument, stating that IBM could set an initial fixed fee without this information from AstraZeneca, although the court recognised that the provision of an IT transfer plan and the duration of the exit period would influence the fixed fee, and that the amount of the fixed fee might change based on these dependencies.

IMPLICATIONS

This case highlights the need to remove any potential ambiguities from exit management provisions in an IT services agreement at the time such an agreement is entered into. It should be considered at the time of negotiation that any interpretation of contractual terms by the courts may act against a party's interests. To avoid unclear wording and achieve a clear contractual plan for exit provisions, an IT outsourcing agreement should provide a carefully detailed exit framework which should be regularly reviewed and updated between the parties prior to the exit.

There are several key steps to follow when addressing exit issues in an outsourcing or IT services arrangement.

  1. At a minimum, focus on the core underlying principles of exit management before the contract is signed.
  2. If you agree to work from an initial high-level exit plan to a detailed exit plan within a few weeks or months of contract start, do so and don't forget it.
  3. Any exit plan should distinguish between assets (of all types) which are used exclusively to support that customer, and multi-client assets. Work out the self-sufficiency plan for both sets of assets.
  4. Know how much input and assistance is required from the service provider on exit.
  5. Agree in advance the cost implications. Try to resist confusing the cost and consequences of effecting a safe and smooth exit with the implications (and possible claims arising from) the circumstances which led to termination. There is no shame in paying for exit, even if it's caused by service provider default, if the result is a smooth transition to another platform with no loss of continuity.

Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Morrison & Foerster LLP. All rights reserved