Platform-change readiness
Translate a platform update, authentication retirement or runtime change into a list of affected assets, accountable owners and practical next steps.
Discuss this engagementDefine the work.
One named platform change and its affected components or integrations. The current official notice and your org's applicability are verified first.
What I investigate
- Affected callers, API versions and integration identities
- Compatibility and behavioural changes
- Certificate, credential and legacy-automation dependencies
- Migration options and representative sandbox rehearsals
What you take away
- Affected asset and owner register
- Dated source references and applicability
- Migration and regression plan
- Rehearsal findings and change sequence
Each affected asset has an owner, an agreed action and a validation path before the applicable change.
Scope notes
Readiness assessment and implementation are separate scopes. Dates and applicability are verified for your engagement, not assumed from a generic checklist.
The proposal confirms access, deliverables, fees, timing and change-control arrangements before work begins.
Where this can lead.
Release assurance
Will this release behave the way we expect?
Explore the engagement Protect & prepareAccess & exposure review
Who can do what—and is that what the business intended?
Explore the engagement Release & changeOmniStudio stabilisation
Why does the same journey work in one org and fail in another?
Explore the engagementBring the problem.
We’ll define the next step.
A release that feels uncertain. A journey that keeps breaking. An org nobody fully understands.