Discontinuing Service Letter: Plan the Client Transition

Decide What You Are Actually Retiring

Name the service and the work it includes. Check whether you're ending the whole offer or replacing a component inside a continuing managed service. Those changes need different explanations, even if both reduce the tools your team supports.

The model favors a standard technology stack. That supports examining an inherited exception, but it doesn't establish that the exception can disappear safely. Document the reason for retiring it and the responsibility you propose to accept afterwards.

Tim Golden says he sometimes talks MSPs out of specialized compliance work when they lack the people or time to deliver it. He recommends examining how the requirement fits the business and whether specialist help makes sense. That's his vendor service-scope advice, rather than a reason to withdraw an existing commitment without a plan.

If the issue is an uneconomic service, check its actual delivery cost before choosing retirement. If the issue is capability, name the capability you can't sustain. Don't describe every withdrawal as an improvement the client is certain to welcome.

Build the Affected-Client Record Before Choosing the Date

Use the service inventory and agreements to establish who receives the work. Include a client who gets it through a bundle or an inherited exception. A search for a separate invoice line may miss those commitments.

Have the owner and transaction or service counsel check the actual agreements where a change needs interpretation. Set the proposed end date from those commitments and the delivery work required. A standard interval copied from another business's letter doesn't establish what applies to this client.

Keep an unresolved client exception visible. If the agreed terms or available replacement don't support the proposed date, resolve that conflict before presenting the date as settled. Changing the website won't resolve it.

Check the Replacement With the People Who Will Support It

Assess the proposed replacement against the client's actual work. Confirm that your support team can deploy and operate it within the scope you're offering. A new supplier logo isn't a transition plan.

Lisa Shorr describes trying a vendor in an office demo and asking her service team about deployment and support experience. That's her firm's selection approach. Use an appropriate evaluation to find what still needs testing for this client's use, rather than treating a sales demonstration as completed validation.

The model calls for a clear monthly fee with its included work stated. Show the recurring service and any separate migration work distinctly in the proposal. Don't imply that agreeing to discuss the replacement means the client has accepted its price or scope.

Erick Simpson recommends explaining how support operates during onboarding and agreeing when ordinary service commitments take over. His practitioner advice applies to a phased transition as well. Make the temporary support arrangement and acceptance point explicit before retiring the old service.

Send a Letter With a Useful Decision

Use the wording below only after the responsible people have accepted the dates and commitments. Replace every bracket with the actual client plan. Keep the same terms in the proposal and the account record.

Subject: Planned End of [Service] and Your Transition Options

Dear [Client Contact], we plan to stop providing [precise service] on [approved end date]. This affects [the work covered]. [The remaining agreed services] will continue under [the relevant agreement], with the scope confirmed in the attached transition proposal.

We are making this change because [specific, accurate reason]. We propose [replacement or alternative arrangement], which would cover [defined responsibility]. The proposal identifies the recurring charge and any separately priced transition work for your review.

[Named contact] will discuss the arrangement with you and coordinate the decisions needed by [supported decision date]. The proposed plan identifies what your team must provide and how support will operate while the work is underway. We will confirm completion against [the agreed acceptance check] before closing the transition work.

Please contact [person and route] to discuss the proposal or tell us that you need an alternative. If this plan doesn't fit your requirements, we'll explain the options we can actually support and record the agreed next step. Regards, [Authorized Sender].

Don't promise unchanged services unless you've checked what continues. If the replacement isn't yet agreed, keep that fact clear in the letter and the account record. A proposal is a decision for the client, not a completed migration.

Follow Up on Decisions and Delivery

Give the account contact responsibility for the client conversation and the project owner responsibility for the transition work. Keep commercial approval with the person authorized to give it. The same colleague may coordinate several steps, but the responsibilities need to remain visible.

Ask the client what prevents a decision rather than repeating the announcement. A dependency may require a changed plan or an accepted alternative. Record the response with the person responsible for resolving it so an unanswered message doesn't become an assumed agreement.

I'd cut the automatic 'successful transition' message until the accepted check has passed. Marketing can't make an untested replacement support the client's work. Have the delivery owner establish what is working and record any remaining exception.

Measure Retirement Through the Remaining Commitments

Track affected clients in the transition register by their actual decision and delivery state. Record accepted alternatives as well as migrations to your preferred service. The number of emails sent or opened doesn't establish which responsibilities have ended.

The count that would change my decision to close the retirement is any client still using the old service with an unresolved commitment. Keep that case assigned, with an agreed next step. Don't close the catalog project merely because the main migration batch has finished.

After acceptance, carry out the agreed billing and data-handling changes. Remove the obsolete offer from sales material and internal work instructions so it isn't sold again by accident. Keep the accepted transition record available to the people who need to understand the remaining service.

Start with the affected-client record and a replacement your team can support. Set the date only when the commitments and delivery plan support it. Then send the letter with a named contact who can carry the decision through to its accepted result.