Recruitment advertising vendor exit: a portability checklist

A recruitment advertising vendor exit plan should identify who controls accounts, creative, destinations, integrations and historical records before the relationship ends. Build a verified handover inventory and test the replacement journey, because receiving an export is not the same as retaining a working recruitment operation.

Key facts

• Record actual access and ownership rather than assuming they are the same.
• Portability depends on contracts, platform rules and the specific configuration.
• Historical reporting, live delivery and applicant handling need separate handover checks.
• Review candidate-data handling with the responsible teams; do not copy everything by default.

What should the exit inventory include?

List the components used in the current workflow: advertising accounts, business access, creative files, landing pages, application forms, feeds, integrations, reporting exports and domain dependencies. Give each item an owner, an administrator and a description of the organisation’s current rights or permissions.

Distinguish ownership from access. Your team may be able to view an account without controlling it, or own a creative asset without having the editable source file. A supplier may operate a connection that depends on credentials issued by your ATS administrator. Each relationship needs its own handover decision.

Ask for documented facts rather than assuming every platform allows the same transfers. Where something cannot be transferred, record the replacement required and its effect on continuity. Have procurement or legal owners review contractual questions; this checklist is operational preparation, not a statement of legal entitlement.

How do you organise a usable portability checklist?

Separate what must continue from what only needs to remain available for reference. An active application form needs a functioning route. An old campaign report may only need a documented export with stable identifiers. Both matter, but they have different acceptance tests.

Component	Evidence to request	Acceptance question
Advertising access	Named account and current permissions	Can the authorised team manage the required activity?
Creative assets	Files, usage conditions and source references	Can approved assets be reused appropriately?
Destinations	Routes, ownership and hosting dependencies	Will campaign links reach the intended pages?
Vacancy feed	Mapping and source owner	Can approved vacancy updates continue?
Applicant handoff	Connection and failure procedures	Will applications reach the right working queue?
Historical reports	Export definitions and identifiers	Can previous results still be interpreted?

Keep credentials out of the checklist itself. Record where access is managed and who can perform the transfer through approved systems, rather than placing passwords or tokens in a shared document.

How should the team protect campaign continuity?

Create a transition sequence with explicit owners. Confirm the replacement configuration, test it, agree the change window and identify how the team will detect a failed handoff. Avoid switching several independent components without a way to identify which change caused a problem.

Inventory active campaign URLs before changing hosting or forms. A destination can remain reachable while its submission route no longer works. Test the full journey using invented applicant information, and verify the record from the recruiter’s normal view.

Use the ATS handoff acceptance test for the delivery boundary. Check retries, attachments and vacancy mapping where relevant. The vendor change should not silently change what recruiters mean by a received application.

Agree how to stop old activity after the replacement is verified. Leaving both suppliers advertising the same vacancy without coordination can create confusing ownership and reporting. The duplicate-job control guide provides a way to reconcile those identities.

What does a handover rehearsal look like?

Consider a hypothetical employer moving a group of recruitment campaigns to a different operating setup. The inventory shows that the employer controls its advertising account but the outgoing supplier hosts the application destination. The reporting export also uses supplier-specific campaign names.

The team first maps the current URLs and vacancy identifiers. It tests a replacement destination and confirms the ATS handoff. It then documents how historical campaign names relate to the new identifiers, preserving the old export rather than rewriting it to look like the new system.

Before changing live routes, the owners agree the transition checks and the response to a failed test. After the change, they verify both candidate-facing pages and recruiter receipt. They only call the handover complete when the required components have passed.

This scenario is an original planning example, not a claim that a particular vendor prevents portability or that migration is always simple.

What should happen to historical and candidate data?

Define what information the organisation needs, why it needs it and who is authorised to receive it. A marketing team may need aggregate campaign results and identifiers without needing full candidate records. Keep the data request proportionate to the actual operating and reporting task.

Have the responsible teams review retention, deletion, access and contractual obligations for the specific relationship. Confirm what happens to data held in the outgoing service and how required records remain available through approved systems. Do not treat a general export capability as proof that every proposed transfer is appropriate.

For restricted assignments, review assets and metadata against the confidential vacancy workflow. Information cleared for one context should not automatically appear in a new public destination or a wider shared archive.

Which questions should be asked before choosing the next supplier?

Ask how account access, creative usage, destination hosting, integration ownership and reporting exports work from the start. Request sample documentation and a practical demonstration where possible. Record limitations in the implementation plan rather than leaving them for a future exit discussion.

Adway publishes an ATS and CRM integration directory. Use it to begin a discussion about the proposed connection, then confirm who owns each dependency and how the configuration would be maintained or replaced. Directory inclusion does not establish contractual portability or a universal migration process.

Bring the current inventory and one representative vacancy to a walkthrough. A concrete dependency map makes the discussion more useful than asking whether a supplier is generally “easy to leave”. To review a proposed workflow with Adway, Book a demo.

Sources

• Adway integrations, directory checked 2 November 2026.
• The inventory, transition sequence and hypothetical handover are original operational recommendations. Contractual and data-handling decisions remain configuration-specific.

Plan the handover while every dependency still has an available owner.