Migrating a job board platform is disruptive. You've already decided to make the move: your current software can't scale, lacks features you need, or costs too much for what it delivers. The question now is how to do it without losing your rankings, your data, or your employers' trust.
This guide covers the complete migration process, including the operational details most guides skip: how to communicate with active employers, what to do with running subscriptions, how to preserve your search rankings, and exactly what to change in Google Search Console after launch.
The technical migration is straightforward. The harder parts are maintaining business continuity and avoiding SEO mistakes that take months to recover from. If you're still evaluating platforms, start with our job board software comparison. Otherwise, let's make sure your migration doesn't crater your traffic or revenue.
What is job board migration?
Job board migration is the process of moving your job board from one software platform to another while preserving your data, SEO rankings, and customer relationships. A successful migration transfers job listings, employer accounts, candidate profiles, and job alert subscribers to the new platform without losing search visibility or breaking active subscriptions. Most migrations take 4-8 weeks when properly planned, with an additional 2-4 weeks of post-launch monitoring.
Before you start: document what you have
Before touching anything, audit what you're actually migrating. Most job board operators skip this step and lose critical data in the process.
Start with Google Search Console. Go to Performance, then Pages, then Export and download your top-performing URLs from the last 12 months. This shows which pages actually drive traffic, not which ones you think matter. Create a spreadsheet with these URLs. You'll use it to set up redirects and verify nothing breaks post-migration.
Keep in mind: the pages worth protecting are your category pages, location pages, company pages, and blog posts. These are the evergreen URLs that accumulate authority over time. Individual job listings come and go after expiry, so don't spend time tracking those.
Document your data: count active job listings, employer accounts, candidate profiles with uploaded resumes, and job alert subscribers. You need exact numbers to verify the migration worked. Screenshot your current platform's data exports if available, and complete all your exports before canceling your old plan. Some platforms restrict or remove data access once you downgrade or cancel, and by then it's too late to recover what you missed.
List every integration: payment processor (Stripe, PayPal), email service provider (Mailchimp, SendGrid), incoming job feeds, analytics (Google Analytics, Plausible), and any embeds or widgets you've placed on other sites.
Screenshot your current settings: pricing tiers, posting duration limits, featured listing costs, email template content, and automated email triggers (job alerts, expiration notices, welcome sequences). Rebuilding these from memory leads to inconsistencies that confuse existing customers.
This documentation takes a couple of hours. Skipping it costs weeks of troubleshooting after launch.
Choosing a destination platform (what matters for migration)
If you haven't settled on a destination yet, our job board software buyer's guide covers how to evaluate platforms based on your business model. For migration specifically, these are the criteria that matter:
Data import capabilities determine whether you spend hours manually recreating listings or complete the transfer in one afternoon. Look for platforms that accept CSV files with flexible column mapping, offer API-based imports for larger datasets, or provide hands-on migration assistance. Some platforms claim to support imports but only accept their exact format, forcing you to reformat hundreds of rows.
Custom domain support is non-negotiable because your domain is your brand. Confirm the platform supports custom domains and understand their DNS setup process. Some platforms walk you through it; others hand you a support article and wish you luck.
URL structure and redirect support matter for SEO. Your old platform used specific URL patterns for job listings and category pages. If the new platform uses different patterns, you'll need 301 redirects, so check whether the platform has built-in redirect tools or if you'll need to handle this yourself.
Timeline to launch varies wildly. Some platforms let you start importing data immediately after signup. Others require sales calls, custom quotes, or waiting periods before you access migration tools. If you're switching because of pricing changes or a platform shutdown, speed matters.
Migration support is rarely included in standard plans. Confirm whether help with data mapping, DNS configuration, and testing is part of onboarding or requires paid professional services.
The 5-phase migration process
Phase 1: Export and clean your data
Start by exporting every data type your platform stores. Most job board platforms offer CSV exports through admin dashboards, typically under settings or data management sections.
Job listings are straightforward: export all active jobs with titles, descriptions, locations, salary ranges, posting dates, and expiration dates. Include category tags, custom fields, and employer associations.
Employer account data requires separate exports. Pull email addresses, company names, contact information, posting history, and active subscription details. If employers have custom branding or logos uploaded, download these separately because CSV exports rarely include file attachments.
Candidate data includes user profiles, saved job searches, application history, and resume uploads. Export email preferences and account creation dates to preserve user standing and subscription status.
Job alert subscribers form a critical email list. Export email addresses with their alert preferences: keywords, locations, categories, and frequency settings (daily, weekly, instant).
Cleaning decisions matter more than most operators realize. Expired jobs older than six months typically don't merit migration unless you maintain an archive for analytics. Inactive accounts that haven't logged in for over a year add database bloat without value. Duplicate listings from employers who reposted the same job multiple times should be deduplicated now, not after import.
Custom fields present the biggest mapping challenge. If your current platform uses fields like "remote flexibility level" or "equity range," verify your new platform supports equivalent fields or decide how to flatten this data into standard categories.
Blog content is easy to overlook. If you've published articles on your current platform, export them with their titles, body content, publish dates, and slugs. You'll need to recreate these on the new platform and set up redirects from the old URLs. Blog posts often carry significant backlink equity and organic traffic that you don't want to lose.
Job feeds and backfill: If your board uses job aggregation to pull listings from sources like Indeed, Adzuna, or employer career pages, document your current feed configuration: which providers, what filters, and how frequently jobs sync. You'll need to reconfigure these on the new platform. Some platforms like Cavuno have built-in backfill and company scraping that can replace manual feed setups entirely.
Screenshot your current platform's data structure before exporting. When you're verifying imports later, you'll need visual reference for how categories, filters, and custom fields originally appeared.
Phase 2: Set up and configure your new platform
Create your account and complete basic platform configuration: site name, contact email, default timezone, and currency settings. These affect how imported data displays, so set them before uploading anything.
CSV import varies by platform. Upload your jobs CSV first since it's the most straightforward dataset. Some platforms auto-detect columns and let you map them to standard fields; others require your CSV to match their exact template. Check your platform's import documentation before formatting your export.
Field mapping requires careful attention. If your old platform called it "employment_type" and the new one expects "job_type," you'll map these manually. When fields don't have direct equivalents, choose the closest match or concatenate data into description fields. Some platforms let you create custom fields during import; others force you to configure these first.
Handling import failures typically means fixing CSV formatting. Common issues: date formats that don't parse (use YYYY-MM-DD), HTML in description fields that breaks parsing (check if the platform accepts HTML or requires plain text), and special characters in company names that need escaping.
Import employer accounts next, then candidate profiles, then job alerts. This order ensures jobs have employer associations when candidates and alerts reference them.
Custom domain connection requires pointing your domain's DNS to the new platform. Most platforms provide nameserver addresses or A records to enter in your registrar's DNS management panel. DNS propagation can take up to 24-48 hours, though changes often appear faster. If you're not comfortable with DNS configuration, look for a platform that offers support during this step. See Cavuno's domain setup guide →
Payment processor setup connects your Stripe account to accept job posting payments and subscription renewals. Link your existing Stripe account to maintain payment history and avoid disrupting active subscriptions.
Recreate your pricing tiers: free listings, featured placements, premium packages, and subscription plans. Match pricing to your old platform or use migration as an opportunity to adjust based on what actually sold.
Phase 3: Handle the SEO transition
Your job board has built search rankings and inbound links over time. The migration can erase that work if you're not careful with the technical handoff.
URL structure decision
Most job board SaaS platforms use URL structures that follow SEO best practices, so your new platform's URLs will likely differ from your old ones. That's fine. It's almost always better to adopt the new platform's URL structure and set up 301 redirects from your old URLs rather than trying to force a custom URL scheme.
Setting up redirects
You need 301 redirects from your old URLs to their new equivalents, but not all pages are equally important. Focus your redirect effort on the pages that carry long-term SEO value: category pages, location pages, company pages, and blog posts. These are the URLs that accumulate backlinks and search authority over time. Individual job listings expire and cycle out, so they're low priority.
Pull your landing pages from Google Search Console for the last 3-6 months. Sort by impressions or clicks. These are your priority redirects. Create a spreadsheet with two columns: old URL and new URL. Don't forget blog posts. If you've published content marketing on your old platform, those URLs need redirects too.
Some job board platforms have a built-in redirect manager. If yours doesn't, you can often set up redirects through your domain registrar or a service like Cloudflare by adding page rules that map old URLs to new ones.
Test your redirects before launch. Pick 10 URLs from your list, enter the old URL, and confirm it lands on the correct new page with a 301 status code, not a 302.
Transferring metadata
Your page titles and meta descriptions influence what appears in search results and affect click-through rate. Export titles and descriptions for your main pages: homepage, category pages, location pages, and any high-traffic evergreen listings.
Most platforms let you set custom titles and descriptions per page. Plug in what was working on the old site.
Structured data for Google for Jobs
Google for Jobs requires JobPosting schema markup on your job listing pages. Your new platform should handle this automatically, but verify it. After migration, grab a job URL and run it through Google's Rich Results Test. You should see "JobPosting" detected with no errors. If you see warnings about missing fields like salary or jobLocation, add them. More complete structured data performs better in Google for Jobs.
For deeper optimization, reference our technical SEO documentation.
Phase 4: Communicate with your users
Most migration guides skip this entirely. That's a mistake. Your users don't care about your new platform. They care about whether their jobs are still live, whether their subscription still works, and whether they need to do anything.
Employers with active job postings
Send an email 1-2 weeks before migration. Keep it short:
- What's happening: "We're moving to a new platform to give you better tools for managing your listings."
- When: "Migration happens on [date]. Expect 2-4 hours of downtime."
- What happens to active postings: "All active jobs will transfer automatically and remain live. No action needed."
- Paid postings: "If you have remaining days on a paid listing, they'll carry over. We're honoring all active commitments."
- Support contact: "Questions? Email us at [email] or reply to this message."
If you have employers with active paid postings, confirm individually that their remaining time will be honored. Don't make them ask.
Handling active subscriptions
You have three options for employers with recurring subscriptions:
- Transfer manually to the new platform. Export your subscriber list, set up equivalent plans on the new platform, and migrate them over. Time-consuming but cleanest for the customer experience.
- Let current subscriptions run out. Announce that current plans continue until expiration, then users re-subscribe on the new platform. Simple but creates friction.
- Offer account credit. Calculate remaining subscription value and issue credit on the new platform. Fair and flexible.
Pick one approach and communicate it clearly. Don't leave people guessing whether they're still being charged.
Job alert subscribers
If you're moving to a new email service provider, you may need subscribers to re-confirm their opt-in. This depends on GDPR, CAN-SPAM, and your ESP's policies.
Send a "we're moving" email before migration: "Our job alerts are moving to a new system. Click here to confirm your subscription if you want to keep receiving them." Include an unsubscribe option. You'll lose some subscribers. That's better than getting flagged as spam on the new platform.
After migration, re-import confirmed subscribers and verify alert triggers work correctly.
Job seekers with accounts
If your job board has candidate accounts, notify them before migration:
- Their account is transferring to the new platform
- They'll need to reset their password on first login
- Saved jobs and application history will transfer (verify this is true before promising it)
Send this the day before or day of migration. Job seekers don't need two weeks' notice. They need to know what to do when they log in and things look different.
Phase 5: Test before going live
You've planned, migrated data, set up redirects, and drafted communications. Now prove it all works before flipping the switch.
Run through the core user flows:
- Application submission: Post a test job. Apply to it as a candidate. Verify the application arrives in the employer dashboard and triggers the right email notifications.
- Payment flow: Create a 100% discount coupon and use it to post a paid job listing. This tests the full checkout flow (payment form, coupon application, job going live) without charging a real card. Most platforms support discount codes.
- Job alerts: Sign up for a test alert. Post a matching job. Verify the alert email fires within the expected timeframe.
- Mobile experience: Open the site on your phone. Navigate to a job listing, apply, and check that forms and buttons work without breaking.
Check your redirects. Pick 5-10 of your most important old URLs. Enter them in a browser and confirm each lands on the correct new page with a 301 status code.
Verify analytics tracking. Navigate a few pages on the new site and check that pageviews are recording in Google Analytics (or your tool of choice).
Structured data verification. Paste a job listing URL into Google's Rich Results Test. Confirm "JobPosting" schema is detected with no critical errors.
Fresh eyes test. Ask someone outside your team to use the site as if they've never seen it. Watch where they hesitate or get confused. Fix those friction points before launch.
After launch: Google Search Console setup and monitoring
Search Console isn't optional post-migration monitoring. It's your early warning system for indexing problems that silently kill traffic. Here's exactly what to do and when.
Day 1
Add your site to Google Search Console if you haven't already. If you changed domains, you'll need a new property.
Submit your XML sitemap. Most platforms serve this at yourdomain.com/sitemap.xml. In GSC, go to Sitemaps in the left sidebar and paste the URL.
Use the URL Inspection tool on your homepage and your 5-10 most important pages. For each one, click "Request indexing." This tells Google to crawl these pages immediately rather than waiting for natural discovery.
If you changed domains, use the Change of Address tool in GSC (under Settings). This helps Google transfer your ranking signals to the new domain faster. You need both old and new domains verified in GSC to use this.
For detailed setup instructions, see connecting Search Console.
Week 1
Check the Index Coverage report (under Pages in newer GSC versions). Look for errors: 404s, redirect chains, server errors, robots.txt blocks. Every error here is a page Google can't index.
Review the "Excluded" pages list. Some exclusions are fine (like tag pages or filters you don't want indexed), but if pages you expect to rank are excluded, investigate why.
Watch for unusual spikes in 404 errors. A few are normal. Hundreds appearing suddenly means broken internal links or redirect problems.
Weeks 2-4
Compare impressions and clicks in the Performance report to your pre-migration baseline. If you followed the first section of this guide, you exported this data before migration.
Verify key pages are indexed by searching site:yourdomain.com/specific-page-url in Google. If nothing appears, the page isn't indexed yet. Use URL Inspection to diagnose why.
Don't panic if rankings fluctuate. Google is reassessing your site. This is expected behavior.
What's normal vs. what's a problem
Expect ranking fluctuation for 2-4 weeks post-migration. Rankings might dip temporarily as Google recrawls and reassesses your content.
If you implemented redirects correctly, most pages recover within 7-14 days.
Major traffic drops that don't recover after 4 weeks signal something went wrong. Check for missed redirects, indexing blocks, or broken canonical tags. If traffic to specific pages disappeared, use URL Inspection to see what Google is seeing.
One thing worth remembering: even if the migration isn't perfect, if the new platform is fundamentally better (faster, better structured, stronger technical SEO), your traffic will recover and often surpass your old numbers. Fix issues as you find them, keep publishing content, and give Google time to reassess. A better platform compounds in your favor over the long run.
5 migration mistakes that tank your traffic
1. Changing URLs without redirects
Every old URL that returns a 404 is lost traffic and lost link equity. If you had a page at /jobs/software-engineer-san-francisco ranking on page one, and now it's a dead link, that ranking disappears. Every backlink pointing to that URL now leads nowhere. 301 redirects are non-negotiable if your URL structure changes.
2. Forgetting job alert subscribers
Your alert list is your most engaged audience: people who asked to hear from you. Lose them and you're rebuilding from zero. Worse, sending alerts from a new email system without proper opt-in risks GDPR and CAN-SPAM violations that carry real fines.
3. Migrating dirty data
Importing 10,000 expired job posts from 2019 doesn't help anyone. It clutters your new site, confuses search engines about what's current, and makes candidates question whether your board is active when every listing they click is already filled.
4. Skipping the test phase
"It looks fine" isn't testing. Submit a real application. Process a real payment. Send a real alert. Issues that seem minor on desktop (a misaligned button, a broken form field) can completely block users on mobile.
5. Stopping monitoring after one week
Many migration issues surface in weeks 2-4 as Google processes changes. Redirect chains that worked initially start causing indexing delays. Pages you assumed were indexed get dropped. Check GSC weekly for at least a month after launch.
Realistic timeline: what to expect
| Week | Phase | Key milestones |
|---|---|---|
| 1 | Planning | Document current state, choose platform, map data structure |
| 2 | Setup | Configure new platform, import cleaned data, connect domain |
| 3 | SEO & comms | Set up redirects, transfer meta data, draft user communications |
| 4 | Testing | Full QA across devices, fix issues, finalize communications |
| 5 | Launch | Go live, send communications, submit sitemap to GSC |
| 6+ | Monitoring | Weekly GSC checks, respond to indexing issues, confirm traffic recovery |
Simple migrations (small job boards with basic features keeping the same domain) can compress to 3-4 weeks. Complex migrations with large datasets, domain changes, or multiple integrations (ATS, payment processors, analytics tools) can push to 8-12 weeks.
The difference between fast and slow isn't cutting corners. It's whether you handled the details upfront or discovered them during testing.
Migrate with confidence
Migration is complex but manageable when you handle the details most guides skip: communicating with your users, getting Search Console right, and monitoring long enough to catch problems before they compound.
If you're looking for a platform that makes migration straightforward, Cavuno offers direct import support, automatic DNS setup for your custom domain, and plans starting at $29/month with no transaction fees on your revenue. Start your migration with Cavuno →




![Cover Image for Job Board Features: The Complete Guide for Operators [2026]](/_next/image?url=https%3A%2F%2Frxjnwynbjvtvqdlqdgqy.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fblog-assets%2Fstatic%2F0dee7220-8bf3-4e3a-b78b-9960bb50711c.jpg&w=3840&q=75)

