The latest burning platform: Exit Plans in a shifting world


The new geopolitical reality brings the possibility that we will have to execute our exit plans closer to home. In this research we delve deeper into exit plans and their implementation and execution.

The current global situation, marked by significant trade tensions and retaliatory measures between major economic powers, has elevated the importance of more detailed, robust, and executable exit plans for businesses in nearly all industries. The current geopolitical headwinds create an unpredictable environment that can severely impact supply chains, technology partnerships, and overall business operations. What was once a prudent measure is now a critical necessity – a “burning platform” – for ensuring business continuity and resilience.

Here I will delve deeper into the essential components of an effective exit plan, outline the practical steps for its implementation, and explain the crucial role of testing in validating its readiness.

The Main Building Blocks of an Exit Plan

An exit plan, at its core, is a comprehensive and well-documented strategy that allows an organization to smoothly transition away from a critical third-party provider, technology, or service with minimal disruption. Think of it as a detailed roadmap for when and how to make a change, ensuring that essential business functions can continue without significant interruption. Several key building blocks are essential for constructing a robust Exit Plan, detailed in the following 9 points.

1. Define your Objectives and Scope

The first step is to clearly define the objectives of the exit plan. What are we trying to achieve by having this plan in place? Is it to ensure continuity of a specific business function, to comply with regulatory requirements like DORA, or to mitigate potential risks associated with a particular vendor or technology? Think further than pure risk issues. Consider financial traps, like, e.g., the Java language issue. The scope of the plan also needs to be clearly defined. What specific services, technologies, or providers does this plan cover? It's crucial to focus on those supporting critical or important business functions (CIF's). Also consider the difference between regulated CIF's and functions critical to your company. They are most likely not the same (although the regulations intend for them to be the same.)  In light of the latest geopolitical “troubles,” you may want to consider looking at local providers.

2. Perform a Business Impact Analysis (BIA)

A thorough Business Impact Analysis is crucial. This involves identifying the critical business functions that provide your firm with income and allow it to perform its services. Additionally, look at functions that are significant to your clients (but maybe less to you), and hence, if they don't perform anymore, can land you in the hot seat with your clients. You need to identify the service, technology, or provider in question that supports this function. We need to understand the potential impact – both financial and operational – if that service or supporting element were to become unavailable. This analysis helps you to prioritize which exit plans are most critical and what resources might be needed for a smooth transition.

3. Assess your risk and Trigger Identification

We must identify the potential risks that could trigger the need to execute the exit plan. These could include performance issues with the provider, financial instability, regulatory non-compliance, technological obsolescence, or, as we're discussing, geopolitical events that make the current arrangement untenable. Establish clear triggers – specific events or conditions – that would initiate the execution of the plan. This is essential.

4. Identify Alternative Solutions

A core element of any exit plan is to identify viable alternative solutions. This will involve identifying alternative providers who can offer the same service, exploring in-house solutions, or even re-engineering business processes to reduce or eliminate the dependency. You must have a well-researched list of alternatives, along with their contact information and preliminary assessment of their suitability, is vital. This brings us up a sensitive topic. The reliance on specific vendors — also called vendor lock-in. Cloud providers have played right into this. Azure, AWS, Google, and others provide powerful functions and native implementations of business-supporting functions. The flip-side is that companies think they can rely on these and still be resilient. Spoiler: you are not resilient if you rely on a single possible supplier to provide mission-critical services.  I refer you to our upcoming cloud-interoperability considerations article. 

5. Develop a High-Level Migration Plan

You must outline the major steps required to transition from the current state to the desired future state. Initially, this doesn't need to be an overly detailed project plan, but it should identify the key phases, major tasks, and estimated timelines for the transition. This plan should also consider how data will be migrated securely and integrally to the new solution. Such a high-level plan includes the following sections:

  1. Preparation
  2. Planning
  3. Solution Building
  4. Network upgrades
  5. A pilot migration
  6. A velocity migration
  7. A cold-data migration
  8. And then bring it all together

In April 2025, I'm not aware of any regulatory requirements to have detailed technical and operational procedures in place. Detailed here means that they explain exactly how you would exit a service at a deep technical level. Be aware that this is something that a some point you will need to have.

6. Define Roles and Responsibilities

It is crucial that you clearly assign roles and responsibilities for managing and executing the exit plan. This includes identifying who will be responsible for initiating the plan, overseeing the transition, managing communication, and ensuring the continuity of business operations. Form a dedicated coordination team involving stakeholders from all affected business areas. My recommendation is to follow the same rules as the crisis management team. The provider is required, depending on your industry, to provide assistance under law. If that is not mandated in your industry, negotiate it in.

7. Communication Plan

A detailed communication plan is plain necessary and required under certain regulations to ensure that all relevant stakeholders – including internal teams, customers, regulators, and the exiting provider – are informed throughout the exit process. This plan should outline what information will be communicated, to whom, when, and through what channels. 

8. Governance and Review Cycles

Establish a clear governance structure for the exit plan, including who has the authority to approve its activation and any significant changes. Your plan must include a schedule for regular reviews and updates to ensure it remains relevant and effective, especially in a rapidly changing geopolitical and technical landscape. I recommend at least an annual review as a minimum. And I recommend reviewing subsections every quarter, as IT and business changes happen much faster today.

9a. Success Criteria

It is crucial you define what a successful exit is. What are the key metrics that will indicate the transition has been completed effectively, and that business operations are continuing as expected? These criteria should be specific, measurable, achievable, relevant, and time-bound (SMART). Remember that no where it is written that you need to be able to migrate like for like. 

9b. Success criteria considerations

Some regulations actually demand that an exit can be executed without any interruption to the services you provide to clients. In my talks with peers and my experience, this is close to a mirage. In other words, the regulators ask for something that is either pretty impossible or can only be realized at extreme costs. This means that you need to have a good answer ready when it comes to audit time, but also must analyze your actual dependencies and what to do about them.

If you are business-dependent on a non-local supplier who may have to comply with their regulator, regardless of your local laws, you must think of substitution. And that may mean rethinking your architecture. 

In my view, the main success criterion is whether you can continue to prove the service to your clients. Ideally in the same way, at the same service level. But if that is not achievable within acceptable financial and time-based boundaries, then the next best option must be considered. Call it a minimum viable plan, upon which you can then continue to build.

What are the next steps in implementing an exit plan?

Once the building blocks of an exit plan are understood, the next step is to put them into action. Implementing an effective exit plan involves a structured approach:

1. Identify Critical Dependencies

The first practical step is to identify all critical and important business functions and map their dependencies on third-party providers, technologies, and services. This mapping exercise will highlight the areas where exit plans are most urgently needed. Do not underestimate this effort. Every department head will want to put their activities as critical, lest they become a target for “efficiency exercises” later on. Clarify your definition of critical service, either within the confines of applicable regulation or as a function of their importance to your bottom line. Clarify that functions not deemed critical are not (immediate) targets for efficiency. 

2. Prioritize Exit Plan Development

Based on the Business Impact Analysis and risk assessment, prioritize the development of exit plans for the most critical dependencies first. Focus on those areas where disruption would have the most significant impact on the business and those that are required for regulatory compliance. 

3. Form an Exit Plan Coordination Team

As mentioned earlier, assemble a dedicated team with representatives from all relevant departments (IT, operations, procurement, legal, finance, etc.) to oversee the development, implementation, and testing of exit plans.

4. Develop Detailed Exit Plans

For each prioritized dependency, develop a detailed exit plan incorporating all the building blocks we discussed. This involves documenting the current state, the desired future state, the steps required for transition, resource needs, timelines, and responsibilities. This is where you will spend the most time. Some plans can be simple: switching telecoms providers for the business is typically easy. Switching standard platform providers already takes some more effort, but the steps are generally well known. Specialty or deeply integrated SaaS solutions will require a lot more work.

5. Secure Contractual Agreements

When engaging with new third-party providers or renewing existing contracts, ensure that the agreements include clear exit clauses, data and function portability provisions, and support for transition activities. These clauses should address termination rights, minimum notice periods, and mandatory transition periods to minimize disruption. You will find that the function portability as demanded by some industry standards will be difficult to come by, and will rely on your capabilities or hired specialty consulting. 

6. Allocate Resources

Ensure that adequate human and financial resources are allocated to support the development, implementation, and ongoing maintenance of exit plans. This includes the personnel needed to create and execute the plans, as well as any potential costs associated with transitioning to alternative solutions. These two lines will form the bulk of your financial involvement, especially when you're integrated deeply with a single cloud provider. Be under no illusion that this plan will be created quickly and easily. I have seen integrations that required complete refactoring of the IT-translated business logic. 

7. Establish a Document Repository

Maintain a central repository for all exit plans and related documentation, giving easy access to authorized personnel. This repository should be regularly updated to reflect any changes in dependencies, providers, or geopolitical circumstances. Do not place your plans in the same cloud or location that you may need to rush the exit. Ideally, place these documents in local storage or even on paper.

8. Communicate and Train

Communicate the existence and key aspects of the exit plans to relevant employees, and provide training on their roles and responsibilities in the event of an activation. Awareness and preparedness are crucial for effective execution.

Testing the exit plan

A well-documented exit plan is only as good as its ability to be executed effectively. Therefore, rigorous testing is the critical final step in the process. Testing helps identify any gaps, weaknesses, or unrealistic assumptions in the plan and ensures that the organization is truly prepared to handle an exit scenario. Different types of testing can be employed:

1. Table-Top Exercises:

These involve bringing together the relevant stakeholders to walk through the exit plan in a simulated scenario. This helps ensure that everyone understands their roles and responsibilities, and that the plan is logical and comprehensive. It’s essentially a “paper evaluation” to check the plan's documentation, understanding, realism, and attainability.

2. Simulation Exercises

These involve simulating a partial or full failure of the critical service or technology to see how the exit plan would be executed in a real-world scenario. This can help identify technical challenges, resource constraints, and communication breakdowns that might not be apparent in a table-top exercise.

3. Data Migration Testing

If the exit plan involves migrating data to a new provider or in-house system, specific testing of the data migration process is essential to ensure data integrity, completeness, and security during the transfer.4

4. Failover Testing

For technology-related exits, failover testing involves switching over to the alternative system or provider to ensure it functions as expected and can handle the required workload.11

5. Full-Scale Exit Drills

In some cases, particularly for highly critical functions, a full-scale exit drill might be necessary. This involves actually executing the exit plan in a controlled environment to validate its effectiveness from start to finish.

Key Considerations for Testing:

Take a Risk-Based Approach: The frequency and rigor of testing should be proportionate to the criticality of the service and the likelihood of needing to execute the plan. Note that the likelihood of exiting is larger now for non-US companies. 
Realistic Scenarios: Testing should be based on plausible scenarios, including those related to geopolitical disruptions.
Lessons Learned: After each test, conduct a thorough review to identify any areas for improvement, and update the exit plan accordingly.
Regular Review and Updates: exit plans are not static documents. They need to be reviewed and updated regularly, especially when there are changes in the organization's dependencies, the geopolitical and economic landscape, or the availability of alternative solutions.

Conclusion

In today's volatile climate, the implementation of robust exit plans is no longer a matter of best practice but a fundamental requirement for business survival and resilience. By focusing on the key building blocks of an exit plan, following a structured implementation process, and rigorously testing its effectiveness, organizations can significantly mitigate the risks associated with disruptions to critical third-party dependencies. This proactive approach will not only ensure business continuity in the face of global uncertainties but also demonstrate preparedness and instill confidence among stakeholders. The “burning platform” of geopolitical instability demands that we treat exit plans with the urgency and attention they deserve.

This research, as always, references several sources to come to this conclusion.

  1. The Digital Operational Resilience Act: What You Need to Know Now — Riskonnect, accessed April 1, 2025, https://riskonnect.com/business-continuity-resilience/the-digital-operational-resilience-act-what-you-need-to-know-now/
  2. 2. exit plan template — NOREA, accessed April 1, 2025, https://www.norea.nl/uploads/bfile/65a0735a-53b7-487e-92b0-b15bf3bccb00
  3. Digital Operational Resilience Act (DORA), Article 28, accessed April 1, 2025, https://www.digital-operational-resilience-act.com/Article_28.html
  4. Cloud exit strategy – testing of exit plans — European Banking Federation, accessed April 1, 2025, https://www.ebf.eu/wp-content/uploads/2020/09/Cloud-exit-strategy-Testing-of-exit-plans.pdf
  5. Atlassian exit plan 2022, accessed April 1, 2025, https://www.atlassian.com/pl/dam/jcr:6190824d-4b0f-4791-b934-d07e9d478416/Atlassian-exit-plan-2022.pdf?cdnVersion=949
  6. How to Develop a Third-Party Vendor Exit Strategy — Julien Haye @ Aevitium LTD, accessed April 1, 2025, https://www.aevitium.com/post/how-to-develop-a-third-party-vendor-exit-strategy
  7. Article 13 Digital Operational Resilience Act (DORA), Communication — GRC Docs, accessed April 1, 2025, https://grc-docs.com/blogs/dora-articles/article-13-digital-operational-resilience-act-dora-communication
  8. DORA compliance: Four tips for enhancing third-party management — Grant Thornton Ireland, accessed April 1, 2025, https://www.grantthornton.ie/insights/factsheets/dora-compliance-four-tips-for-enhancing-third-party-management/
  9. Meeting EU Digital Operational Resilience Act (DORA) Third-Party Risk Requirements, accessed April 1, 2025, https://www.venminder.com/blog/meeting-eu-dora-third-party-risk-requirements
  10. 25 DORA Requirements Explained — Faddom, accessed April 1, 2025, https://faddom.com/25-dora-requirements-explained/
  11. European Banking Federation Guidance on testing of Cloud Exit Strategy — Stibbe, accessed April 1, 2025, https://www.stibbe.com/publications-and-insights/european-banking-federation-guidance-on-testing-of-cloud-exit-strategy