Staging to Production Wordpress Migration

We operate a content publishing and training business on WordPress.com. The site has been live since 2010 and carries an active blog, a popular podcast catalogue, a substantial newsletter list, and several program landing pages. The current production site uses a custom theme. Over the past weeks we’ve rebuilt the key public-facing pages on a WordPress.com staging clone — new hero, new positioning, new newsletter page, updated podcast page, deleted news page, restructured navigation. We are now ready to take the new build to production. We need a developer (or agency) to execute the cutover end-to-end in 4 working days without losing content, breaking SEO, or interrupting newsletter signups. The production domain and access credentials will be shared with the awarded developer. After award, we will send a short video walking you through several specific copy and structural changes we want made during the migration window. Those are scoped on top of the 10 deliverables listed below. Timeline — 4 working days DayFocus Day 1Backup current production (content + theme + uploads + plugins) and verify a successful restore in a local environment. Begin content sync — pull every post and page published on production since the staging fork and import the delta into staging. Day 2Plugin audit. URL preservation crawl, redirect map. Newsletter form wired to Mailchimp end-to-end and tested. Apply the specific changes from the post-award video. Day 3Configure Jetpack Instant Search. Confirm every blog post is indexable, in the sitemap, and surfaces in on-site search. Footer navigation verification. Broken-link crawl pre-cutover. Lower DNS TTL in preparation for cutover. SEO settings reviewed (especially “Discourage search engines”). Day 4DNS cutover. Post-launch plugin smoke-tests — Mailchimp integrations first, then every other retained plugin. Post-launch verification (forms, embeds, analytics). Rollback plan documented and standing by. Final crawl over the live site. The 12 deliverables 1. Full backup AND local download of current production Run a Jetpack Backup of production. Export the database, all content (WXR), the active theme folder, the uploads folder, and the plugins folder. Download all artifacts to local storage. Restore-test the backup in a local environment (Local WP, Docker, etc.) and confirm it boots. A backup that hasn’t been restore-tested is not a backup. 2. URL preservation — no slugs may change Crawl current production with Screaming Frog. Diff against the new staging sitemap. Every URL that exists on production today must either (a) exist on the new site at the same slug, or (b) have a 301 redirect to a new slug. No exceptions. Document every change in a redirect map. 3. Content sync — production → staging delta Production has been live and accruing content while staging was being rebuilt. Identify the date staging was forked. Pull every post, page, image, and custom-post-type item published on production after that date and merge it into staging before cutover. Confirm the latest content on staging matches production. Re-verify the edits we made to staging weren’t overwritten in the merge. 4. Newsletter form → Mailchimp wiring The form on /newsletter/ currently has action="#" — a placeholder. Wire it to our Mailchimp audience (we will share the audience ID after award). Configure double opt-in, welcome email, and ensure SPF / DKIM / DMARC are set on the sending domain. Submit a real test email and confirm it lands in Mailchimp and in Gmail, Apple Mail, and Outlook inboxes (not spam). 5. Search engine visibility Settings → Reading: confirm “Discourage search engines from indexing this site” is unchecked on the production-bound site. Confirm robots.txt does not block crawling. Confirm meta robots is index, follow. Confirm canonical tags point to the production domain, not the staging subdomain. 6. Footer navigation — every production footer link must work on the new site Pulled live from production, every link in the footer must resolve with a 200 on the new site or have a 301 to a working URL: Affiliates, Contact, Presiding Partner, Honor Code, Strategy Studies, Leadership, Growing a Firm, Titans of Strategy, Startups, Books, Rapid Results, Career ROI, Blog, Podcasts, Corporate, About, Subscribe, Leader vs. Analyst, Coaching, Partner’s Picks, Manage Account, Apps, Role Models, Privacy Policy, Terms of Use, Sitemap, plus all app-store badges and social icons. 7. Broken-link crawl + redirect verification Crawl staging pre-cutover and the live site post-cutover. Fix every 4xx and 5xx. For every 301, verify with curl -I that it returns a 301 (not 302), lands on a 200 (not another 301), and renders correctly. 8. DNS cutover + rollback plan Lower DNS TTL on existing records to 300s at least 24 hours before cutover so propagation is fast. Confirm SSL is provisioned for both the apex and the www subdomain. Update DNS at cutover. Verify with dig and a fresh browser session from a non-cached network. Document the rollback procedure in writing: who triggers it, exact DNS records to revert to, where the backup lives, and the restore command sequence. 9. Plugin audit Inventory every plugin currently installed and active on production. Categorize each into: (a) keep — essential, (b) keep — useful, (c) deactivate — not in use, (d) remove — legacy, broken, or replaced. We want to remove inactive plugins entirely and cancel the corresponding paid subscriptions to reduce ongoing cost. Deliver the audit as a short table with your recommendation per plugin and the annual cost of each paid plugin so we can confirm cancellations. 10. Add live search using Jetpack Instant Search Enable and configure Jetpack Instant Search so the site has search-as-you-type functionality. This replaces the production site’s custom search overlay. The Jetpack Instant Search panel should be styled to match the new brand (Cardo serif, Inter sans, #d8613c accent). Configure filters appropriately (content type, taxonomy as relevant). Test on desktop and mobile, in incognito. 11. Plugin functional verification — especially Mailchimp Beyond wiring the new newsletter form (#4) and deciding which plugins to keep (#9), every retained plugin must actually work end-to-end after cutover. Mailchimp is the priority — confirm every Mailchimp integration on the site (newsletter signup form, popups, embedded forms in posts, footer signup, any sidebar widgets) submits successfully to the correct audience and triggers the correct welcome flow. Also test every other retained plugin’s primary function — payments (Stripe / PayPal), analytics (Google Site Kit / GA4), SEO (Yoast or equivalent), forms, caching, Jetpack modules. Deliver a short post-cutover smoke-test report: plugin name, what was tested, pass/fail, evidence (screenshot or note). 12. Preserve blog discoverability — Google and on-site search The blog is no longer prominently promoted, but it is a significant source of organic traffic and that traffic must be preserved. Important context for the developer: in the backend, the blog is called “Quarterly” — that is the post type / section name you will see in the WordPress admin and in URLs. Public-facing posts live under /quarterly/ (and possibly also /blog/). Treat both paths as in-scope. Every existing Quarterly / blog post (in addition t every other page and blog) and every archive page must remain fully discoverable: Every post URL under /quarterly/ and /blog/ (and any sub-paths such as /quarterly/thank-you-letters/) resolves with a 200 on the new site (or has a 301 to a working URL) Every post is indexable: meta robots index, follow, no noindex accidentally applied, no canonical pointing elsewhere Every post is present in the XML sitemap submitted to Google Search Console The Quarterly / blog index, category archives, tag archives, taxonomy filters (?type=...), author archives, and pagination all work Posts surface in Jetpack Instant Search results (deliverable #10) — not just pages. Confirm with searches for known post titles. If “Quarterly” is a custom post type, make sure Jetpack Instant Search is configured to index it. Posts render correctly in the new theme: typography, images, embeds, internal links, related-posts widgets Submit a fresh sitemap to Google Search Console and Bing Webmaster Tools at cutover; monitor the coverage report for at least 48 hours and fix any crawl errors that appear Deliverable: a Screaming Frog (or equivalent) export of every Quarterly / blog post URL with status code, indexable Y/N, presence in sitemap, and presence in Jetpack search results. Plus a spot-check of 10 sample posts rendered in the new theme with screenshots. Process after award Once awarded, we will send you: A short video (under 10 minutes) walking you through several specific copy and structural changes we want made on selected pages during the migration window. These are scoped on top of the 10 deliverables above. WordPress.com admin access (we will add you as Administrator). Credentials for the Mailchimp audience, the production domain registrar, and Jetpack. A direct point of contact for clarifying questions during the 4 days. What we want in your proposal Please include all of the following: Day-by-day plan for the 4 working days — what you would do on each day, in what order, and what artifacts you would deliver at the end of each day. Fixed fee for the project, broken down into the 12 deliverables. Identify whether you are an individual or an agency. If you are responding on behalf of an agency, please say so explicitly — state the agency name and which person on the team would be the lead developer. Risks you see in this scope and how you would mitigate them. Rollback plan if cutover goes wrong. Your time zone and your hours of availability across the 4 days. Rules for the proposal Do not use AI to write your proposal. We want to see how you write and how you think. Proposals that are obvious AI output will be rejected. We will ask follow-up questions; AI-assisted proposals tend not to survive them. One round of clarifying questions is fine. If anything in this brief is unclear, ask before quoting. No vague scope. Quote the 12 deliverables exactly as listed. If you think a deliverable should be expanded, say so — don’t silently change the scope in your proposal. If the scope is too larger, also tell us. Reference materials we’ll share on request Read-only access to staging so you can audit the work before quoting.