An applicant tracking system gives recruitment teams one place to manage vacancies, candidate records and routine communication. Its value, however, depends heavily on how it is introduced. Decisions about workflows, data migration, integration testing and user responsibilities will determine whether the system becomes part of everyday recruitment or simply adds another layer of administration.
Implementing an ATS is just as much about operations as it is about technology. A reliable recruitment setup needs clear approval steps, candidate stages, templates, permissions, reports, careers pages, and links to other systems. Oracle’s documentation shows this range by covering application flows, selection steps, requisitions, offers, questionnaires, candidate pools, and agency hiring (Oracle).
There is no single timeline that fits every ATS implementation. For a small team, setting up a simple system may take 2 to 4 months with minimal setup. Rolling out a system across several countries with old data and many integrations can take 6 to 12 months or more because of extra discovery, testing, and change management. Only set a launch date after both the vendor and your team agree on the scope and dependencies.
Here are eight practical steps for employers who are switching from spreadsheets, upgrading from an older ATS, or rolling out a new platform to a larger recruitment team.
1. Define What the ATS Must Improve
Start by looking at your recruitment process, not just the features. If the project is only described as “implement the new ATS,” the team won’t have a clear way to set priorities or judge if the rollout was successful.
Document the problems that led to the purchase. They may include:
- Unclear ownership of job requisitions
- Repeated manual entry across several systems
- Inconsistent screening or rejection records
- Delayed interview scheduling and candidate communication
- Limited visibility into recruitment sources and costs
- Weak control over candidate information
- Reports that cannot be trusted because stages are not updated consistently
Translate each question into a clear requirement and a result you can see. For example, if hiring managers usually approve vacancies by email, set up a tracked approval process with named approvers and escalation rules. If recruiters don’t know where good applicants come from, require consistent source tracking with clear field definitions.
Document your current starting point before making changes. Useful measures might be how long approvals take, how many records have a completed source field, overdue candidate follow-ups, or how often the agreed workflow is used. These help you see if the new process is working and where it needs improvement.
Clearly state which business units, countries, job types, integrations, and old records will be part of the first launch. Save future ideas for a separate list. Trying to include every feature at once makes testing and training harder and can delay your go-live date.
2. Assign Decisions Before the Vendor Kickoff
The vendor knows the product, but you are still responsible for your recruitment process, candidate data, and internal decisions. So, a good kickoff meeting needs more than just the supplier and HR in the room.
Create a small implementation group with defined authority:
| Executive sponsor | Removes organizational barriers and resolves major scope or resource issues |
| Project lead | Controls the plan, decisions, dependencies, risks and communication |
| Recruitment process owner | Approves workflows, field definitions, templates and operating rules |
| System administrator | Controls configuration, permissions, documentation and future changes |
| IT or integration lead | Reviews identity management, data flows, interfaces and technical testing |
| Privacy, legal or security representative | Reviews data use, retention, access, contracts and applicable obligations |
| Recruiter and hiring manager representatives | Test real working scenarios and identify impractical requirements |
| Vendor implementation lead | Explains platform constraints, completes agreed supplier tasks and manages product-side issues |
In smaller organizations, one person might handle several roles, but each decision should still have a clear owner.
Use the kickoff to confirm:
- The scope and expected outputs of each implementation phase
- Responsibilities on both sides, including data and integration work
- Milestones, dependencies, review dates and issue escalation
- The environments available for configuration and testing
- Training and launch assistance included in the agreement
- The process for approving changes to scope
Before you sign the contract, talk to customers with similar hiring needs, integrations, and company size. Ask them about migration issues, training quality, and post-launch support, not just their overall opinion of the product. Also, check the vendor’s support agreements, how open they are about their product plans, how often they update, and how flexible they are with integrations. Make sure the vendor is honest about system limits, has clear ways to handle problems, and communicates regularly. Knowing these things helps you choose a partner who is able to support your organization as it grows and changes.
3. Redesign the Recruitment Workflow Before Configuring It
Don’t let your new ATS simply copy over a process that doesn’t work well. First, map out how recruitment works now, from the first vacancy request to moving a successful candidate into onboarding or your HR system.
For each stage, identify:
- Who starts and approves the action
- What information is required
- Which decisions are made and how they are recorded
- What communication is sent to candidates and internal users
- Which exceptions occur in practice
- What enters or leaves another system
- Which record is expected to provide the authoritative data
Next, design your future workflow. Get rid of duplicate approvals, unused fields, and overlapping stages. Make sure everyone agrees on what terms like screened, shortlisted, interviewed, offered, and withdrawn mean. If recruiters use these terms differently, your reports won’t be reliable.
Not every vacancy should follow the same recruitment route. High-volume hourly hiring, graduate programs, and executive search involve different levels of screening, assessment, and approval. Hourly recruitment may rely on shorter applications and group interview scheduling to process candidates efficiently. Graduate hiring often includes assessment centers, structured group exercises and qualification checks, while executive appointments may require several interview stages, detailed referencing and approval from senior leaders. Keep the number of workflows manageable, document each one and make sure every variation has a practical reason.
Automation also requires judgment. Define which candidate messages the system may send automatically, what action triggers each message, and who is authorized to edit the content. An application acknowledgment can usually be automated without difficulty. A rejection following a final interview is better reviewed and communicated personally by the recruiter.
Agree on the new recruitment process and obtain formal approval before detailed system setup begins. If requirements continue to change after configuration is underway, the vendor may have to rebuild workflows, revise integrations and repeat parts of the testing process.
Data migration is not an exercise in copying every record from the old system. Decide which information remains relevant, whether it is accurate enough to retain, how it should appear in the new system, and whether there is a valid reason to keep it. Candidate communication, interview notes, sourcing details, consent records, attachments and diversity information may be spread across several systems or files. Record where each data set is held, who owns it, which period it covers, its format and the level of sensitivity involved.
Next, decide what to migrate, archive or delete. Consider:
- Whether the information is still accurate and useful
- Whether duplicate candidate profiles can be resolved
- Whether old recruitment stages can be mapped meaningfully to the new pipeline
- Whether there is a valid legal basis for continuing to process the information
- Whether attachments contain outdated, unnecessary or sensitive information that should be removed
- Whether historical reporting requires individual records or can rely on anonymized data
- Whether local legislation, contractual obligations or limitation periods affect how long the records must be kept
Retention periods should not be copied from another employer without checking the applicable legal and operational context. The UK Information Commissioner’s Office, for example, states that data protection law does not prescribe a single universal retention period for recruitment records; organizations should define and justify their own retention periods and should not retain information longer than necessary (ICO). Employers operating elsewhere need advice based on the laws that apply to their candidates and processing activities.
Retention periods for recruitment data should be based on the laws that apply in each country where candidate information is processed, as well as the organization’s genuine operational needs. Legal and data protection specialists can help determine whether records are required for audits, reporting, regulatory obligations or potential employment claims. Document the reason behind each retention period rather than adopting a standard timeframe without justification. Review the schedule regularly to ensure it reflects changes in legislation, regulatory guidance, and business requirements. A documented approach also gives the organization a clear basis for explaining its decisions to auditors, regulators or candidates.
Prepare a field-mapping document that shows where every item from the existing system will appear in the new ATS. Define permitted values, date formats, candidate stages, record owners and the treatment of missing or invalid information. Before moving the complete data set, run a trial migration using a representative sample. ATS providers may also require customers to map old recruitment stages to the new workflow and approve a sample import before the full migration begins. Workable’s published migration process provides one example.
Review the results after every test migration. Record totals, attachments, stage histories, field values, consent details, permissions and search results should all correspond with the source data and the agreed mapping rules. The presence of a candidate record alone does not confirm that its information was transferred accurately.
The cutover plan should state when users must stop entering information into the old system, how updates made during the migration period will be handled, and when the former platform will become read-only. Keep a verified backup and a recovery procedure in place until the migrated data has been checked and formally accepted.
4. Configure Integrations, Permissions and Candidate-Facing Pages
An ATS rarely operates alone. It may exchange information with a careers website, job boards, email and calendar services, assessment providers, background-screening platforms, onboarding software, an HR information system, identity management tools and reporting applications.
For every integration, document:
- The business purpose and accountable owner
- The information sent in each direction
- The system that owns each field and triggers the transfer
- Authentication and access requirements
- Error notifications, failed transactions, and recovery steps
- The party responsible for ongoing monitoring
Test integrations all the way through, not just to see if a connection works. For example, a job might look right in the ATS but show the wrong location on the careers page. An accepted offer could move to the HR system but lose the candidate’s start date. Meeting invitations might work for recruiters but not for outside interviewers. These are process failures, even if each system is running.
Access should reflect job responsibilities. Access must match each person’s job. Recruiters, hiring managers, interviewers, agency users, admins, and auditors don’t all need the same access or editing rights. Follow the concept of least privilege: only give users what they need to do their jobs (OWASP). Test permissions using accounts for each role, not just the admin view. For explicit privacy information, consent choices, questions, confirmation messages, and accommodation guidance. Test on common mobile and desktop browsers and with assistive technology where possible. The W3C’s WCAG 2.2 framework delivers testable criteria for making web content and applications more accessible to people with disabilities (W3C).
5. Test Complete Hiring Scenarios, Not Isolated Features
Vendor testing checks if the product works as designed. User acceptance testing checks if the setup works for your actual recruitment process. You need both types of testing.
Build the test cases around the approved recruitment workflow and agreed system requirements. For each scenario, record the starting point, the user performing the task, the actions to complete, the expected outcome, and the evidence needed to confirm that the test has passed. Cover routine recruitment activity as well as realistic exceptions, including:
- Opening, approving, posting and closing a requisition
- Receiving applications from different sources
- Moving candidates through each authorized stage
- Detecting or handling duplicate profiles
- Scheduling interviews and collecting scorecards
- Rejecting, withdrawing and reconsidering candidates
- Creating and approving an offer
- Transferring a successful candidate to onboarding or the HR system
- Enforcing access, deletion and retention rules
- Producing required reports
- Recovering from a failed integration or undelivered message
Use migrated records as well as newly created test data. Microsoft’s implementation guidance recommends that business users perform user acceptance testing in a dedicated, integrated environment using plausible scenarios, defined success criteria and migrated data where relevant (Microsoft).
Recruiters should lead process testing, while hiring managers examine approvals and feedback, IT verifies interfaces and failure handling, and privacy or security representatives inspect data controls. Forms, messages, as well as accessibility also need testing from a candidate’s perspective.
Sort defects by how serious they are. A spelling error in an internal label can wait, but a permission error that exposes candidate data, a broken application form, or a wrong offer approval process should stop the launch. Make sure any remaining risks are formally approved.
If the ATS includes matching, ranking, summarisation or screening based on artificial intelligence, test those functions separately. Define their intended use, the information they rely on, the role of human reviewers, known limitations and the route for investigating questionable results. The NIST AI Risk Management Framework delivers a voluntary, cross-sector structure for governing, mapping, measuring and managing AI risks throughout deployment and use (NIST). Local employment, equality, and data protection requirements may impose additional obligations.
6. Train People for the Decisions Their Role Requires
Showing the product only once isn’t enough for training. Users need to learn both how the system works and the recruitment rules it supports.
Create role-specific learning:
- System administrators need configuration control, user management, audit, reporting, and vendor escalation procedures.
- Recruiters need the full hiring workflow, candidate communication, data-quality rules, exceptions and reporting duties.
- Hiring managers need requisition approval, candidate review, interview feedback, and decision responsibilities.
- Interviewers may need only secure access to assigned candidate information and scorecards.
Use the oTrain users with your actual system and real job openings. Let them practice tasks in a safe setting instead of just watching presentations. Provide short guides that show the right way to do common tasks and where to get help. Process changes directly. If hiring managers previously sent feedback by email but must now complete a scorecard, explain what changed, why the record is required, and when it is due. Users are more likely to work around a system when they do not understand the operating rule behind it.
Choose a small group of confident users to handle common questions during the launch period and flag recurring problems to the implementation team. Once employees have worked with the ATS in real situations, offer follow-up training to address gaps that were not apparent during the initial sessions. ATS training should also become part of the standard onboarding process for new recruiters and hiring managers.
7. Manage the Launch and Early Weeks of Use
Choose a rollout method that reflects the size and complexity of the implementation. A smaller employer with few integrations may be able to introduce the ATS across the organization at once. A larger or more complex business may prefer to begin with one department, location or recruitment workflow before extending access more widely.
A pilot should have a defined purpose, timeframe and completion criteria. Select a group with engaged managers, reasonably stable recruitment practices and the capacity to provide useful feedback. Agree in advance how the results will be judged, using measures such as user participation, data accuracy, process completion and the number of unresolved defects.
If the old and new systems will operate at the same time, give users precise instructions about which vacancies and candidates belong in each platform. Without clear boundaries, recruiters may update both records, miss important information, or create duplicate work. Employees outside the pilot group should also know what is changing, when the broader rollout is expected, and whether the pilot affects any shared recruitment activity.
Once the pilot ends, review the results with recruiters, hiring managers, administrators, and other relevant stakeholders. Resolve significant problems, update the process and incorporate the lessons into training before introducing the ATS to the next group.
Before launch, confirm that:
- All critical defects have been resolved or formally accepted by the authorized owner.
- The final data migration has been checked against the source records.
- Integrations and role-based permissions have passed testing.
- Careers pages, application forms and candidate messages have been approved.
- Users have active accounts, appropriate training and clear support instructions.
- Administrators know how to monitor system errors, integration failures and audit activity.
- Access to the former system is controlled, and its eventual retirement has been planned.
- Internal specialists and vendor support will be available throughout the agreed launch period.
Don’t launch right before a big hiring push, a public holiday, or when key team members are away. The earliest possible date isn’t always the safest or best time to go live.
Expect more questions and problems during the first few weeks. Give users one place to report them so nothing is lost across emails, calls or informal messages. Review new issues daily during the first week and keep a shared list of confirmed faults, their priority and any temporary solution available. Record suggestions for new features separately, allowing the team to concentrate on problems affecting current vacancies, candidate records or communication.
8. Review Adoption and Data Quality After Launch
Do not judge the ATS solely on its first few days of use. Allow enough vacancies to move through the system so that patterns in user behavior, workflow compliance, and record quality become visible. An initial review after several weeks can identify early problems, followed by a more complete assessment once the organization has processed a meaningful number of recruitment cycles—often around three months, depending on hiring volume.
Use measures connected to the original set of objectives:
- Adoption: active users, scorecard completion and use of agreed approval routes
- Data quality: missing source fields, overdue stages, duplicate records and inconsistent rejection reasons
- Process performance: approval time, scheduling delays, candidate follow-up and stalled applications
- System reliability: integration failures, undelivered messages, access incidents and support requests
- Candidate experience: application abandonment, accessibility problems, response times and direct feedback
- Reporting confidence: whether reports can be reproduced and traced to consistently recorded activity.
Recruitment figures need context. A shorter time to hire may reflect a smoother process, but it does not prove that better candidates are being selected or treated well. An early rise in support requests may simply show that employees are actively using the ATS and asking questions. Compare results with the pre-launch baseline, investigate what caused any noticeable change and, where relevant, examine individual workflows or business units rather than relying only on organization-wide averages.
Avoid making informal changes to the system whenever a user raises a request. For every significant adjustment, record why it is needed, who approved it, how it was tested, and when it was introduced. This discipline prevents duplicate stages, conflicting templates, and reports based on inconsistent definitions from gradually accumulating in the ATS.
9. Warning Signs That the ATS Is Not Ready to Launch
Delay or narrow the rollout if any of the following remains unresolved:
- Nobody can state who owns the recruitment process after the vendor hands over.
- Data was imported, but record counts, field mappings, and permissions were not reconciled.
- Testing covered demonstrations rather than complete hiring scenarios, and hiring managers have not used the configured process.
- Candidate privacy information, retention rules, or user access remain undecided.
- Critical integrations have no owner or failure procedure, and training does not explain the operating rules.
- Success is defined only as meeting the launch date.
It’s better to delay the launch than to go live with a system people can’t trust. If a problem only affects an optional integration or one business unit, you might be able to launch a smaller version first. Make your decision based on documented risks, not just pressure to meet an early launch date.
To make clear go/no-go decisions, list out the risks. Identify and write down any issues that could affect system readiness, including their possible impact (like data privacy, compliance, user adoption, or disruptions) and how likely they are. Rate how serious each risk is and assign someone to handle it. Put all risks in one place that stakeholders may see. Share these risks, along with plans to address them or any open questions, so managers can decide whether it’s safe to launch or wait. This procedure helps everyone take informed decisions at key points.
10. Begin with a Signed Implementation Charter
The best way to start is with a short implementation charter, approved by the sponsor, process owner, and vendor. This document needs to outline the problems you’re solving, the project scope, responsibilities, milestones, data plan, who approves testing, the training plan, go-live criteria, and what you’ll measure in the first review.
This document provides your project with a solid foundation for decision-making. It also makes it clear from the start: the vendor is responsible for delivering the technical service, while you are responsible for creating a recruitment process your team can use, candidates can understand, and your organization can support.
