A DMS (Device Management Service, formerly MDM) migration should trigger four specific changes to your IT support contract: compliance reporting scope, patch management ownership, self-service catalogue support, and licensing pass-through. That a platform migration warrants a scope review at all is already established ground, covered in Co-Managed IT: Who Actually Owns What? A Responsibility Matrix for Mac-First Businesses. What follows here is the part that the piece doesn’t cover: the actual line items to change and how to have that conversation with your MSP.
Which specific line items should change when your DMS platform changes?
Four areas of a typical IT support contract are directly affected by a DMS migration, and each needs an explicit decision rather than being left to carry over by default.
- Compliance reporting scope. If your MSP’s reporting for Cyber Essentials or ISO 27001 was built around your old platform’s audit trail, that reporting mechanism does not automatically carry over to the new one, whether you’re moving from a third-party DMS to Apple Business DMS or the other way round. The contract should state who rebuilds it and by when.
- Patch management ownership. Patch deployment cadence and responsibility often shift when the underlying platform changes, particularly if the new platform has different automation capabilities. Confirm explicitly who is accountable for patch compliance during and after the migration.
- Self-service catalogue support. Feature parity for a self-service app catalogue is rarely one-to-one between DMS platforms, in either direction. If your contract included support hours tied to maintaining that catalogue, those hours need reallocating, not quietly dropping.
- Licensing pass-through. Any per-device or per-seat licensing your MSP was passing through under the old platform needs re-quoting under the new one, since per-device DMS pricing structures are not identical across providers.
None of these is abstract. Each is a specific line in a statement of work that either changes or it doesn’t, and leaving it unaddressed is how scope creep or scope gaps happen quietly, months after the migration is technically complete.
What’s a fair way to raise a scope conversation with your existing MSP?
The fairest way to raise it is to name the migration as the trigger point directly, rather than raising it as a general dissatisfaction with cost or service. A scope conversation framed around “our platform changed, so our contract needs to reflect that” is a straightforward, factual request that most MSPs will recognise as reasonable, since the same logic applies in reverse if their costs increase.
Dr Logic’s recommendation is to bring a short written list of the specific line items affected, similar to the four above, rather than opening the conversation with a request for a general discount. A scoped conversation gets a scoped answer. An open-ended one about cost tends to get an open-ended, unhelpful answer back.
Should this happen before or after the migration itself?
Ideally before. Raising the scope conversation before migration means the contract terms are agreed while both sides still have full flexibility, and it avoids a situation where your MSP is already partway through delivering under an outdated scope. If the migration is already underway or complete, treat the first working day after cutover as the deadline for this conversation, not something deferred to your next renewal date, since deferring it means paying for undefined scope in the meantime.
Getting this timing right is exactly the kind of decision our IT Strategy service can help structure properly, particularly if you’re planning the migration and the contract review at the same time.
What should you ask for in writing once the scope changes?
Ask for an updated schedule or statement of work that names the specific deliverables, not just an adjusted monthly rate. A revised rate without revised deliverables tells you nothing about what you’re actually paying for. At minimum, get written confirmation of: which party owns compliance reporting going forward, expected response times for patch-related issues, and a named point of contact for anything that falls outside the newly rebuilt scope. Verbal assurances during a call are not a substitute for this, however reasonable the conversation felt at the time.
What this means for your business
A DMS migration is frequently treated as a purely technical project, handled between the fleet manager and the MSP’s engineers, with the commercial contract left untouched until the next renewal. That gap is where businesses end up paying for support hours against a platform that no longer exists, or discover during an audit that nobody was actually accountable for compliance reporting during the transition. Treating the contract review as part of the migration project, rather than a separate administrative task for later, closes that gap when it’s cheapest to do so.
If you’re planning a DMS (or MDM) migration and haven’t yet reviewed what it means for your support contract, book a free IT assessment.
Related articles
- Co-Managed IT: Who Actually Owns What? A Responsibility Matrix for Mac-First Businesses
- Moving from Fully Outsourced to Co-Managed IT: What the Transition Actually Involves for a Mac-First Business
FAQs
Do I need an entirely new contract when I change DMS platforms, or just an amendment?
Usually just an amendment or an updated schedule, not a new contract. Most IT support agreements separate the core terms from the specific scope of work, so a DMS migration typically only requires the schedule or statement of work to be revised, provided the underlying agreement allows for scope changes without a full renegotiation.
How much notice should I give my MSP before migrating our DMS platform?
As much as practically possible, ideally at least four to six weeks before migration begins. This gives your MSP time to plan the compliance reporting rebuild, confirm patch management ownership, and requote licensing, rather than reacting to a migration that has already started.
What happens to Cyber Essentials compliance reporting during a DMS migration?
Compliance reporting typically has a gap during transition unless explicitly planned for, since the old platform’s audit trail stops and the new one needs to be configured before it can produce equivalent reports. Confirm with your MSP or certifying body how this gap is documented before your next Cyber Essentials renewal.
Should I expect a lower cost when moving from a third-party DMS to Apple Business DMS?
Not automatically. Apple Business DMS itself is free, but your MSP’s cost was rarely just a licence pass-through. Support hours, compliance reporting, and rebuilt configuration work still carry a cost, so the fairer question to ask is what specifically changes in scope, not whether the invoice total falls.
