How to migrate a PTA website without losing parents

Every board that’s outgrown its website vendor has the same conversation, and it stalls at the same sentence: “but what happens to everyone we’ve already reached?” The site everyone bookmarked, the newsletter list built up over four years, the calendar link in three hundred parents’ phones — the fear isn’t the migration itself, it’s the version where half your community quietly falls off because a link broke or an email never landed.

That fear keeps boards on vendors they’ve outgrown for years longer than they should. It’s also mostly avoidable. A PTA website migration only loses parents when nobody plans for the four things that actually carry your audience: the URL, the email list, the calendar, and the redirect. Handle those deliberately and the switch is invisible to the people you’re switching for. Here’s exactly how.

Why do boards stay on a vendor they have outgrown?

Before the how-to, it’s worth naming why this specific fear is so sticky. A PTA website isn’t just content — it’s the thing a stressed parent bookmarks in September and doesn’t think about again until they need the permission slip deadline in November. Any friction in that path (a dead link from a Google search, an unsubscribed newsletter, a calendar that stops syncing) reads to that parent as “the PTA is disorganized,” not “the PTA switched vendors.” The reputational risk is real. But it’s a planning problem, not a reason to stay put — and staying put has its own cost, which is every year of the old vendor’s bill and every year the site keeps looking the way it looks now.

The boards that migrate cleanly all do the same four things, in roughly this order.

1. Preserve the URL, or redirect every one that changes

This is the single highest-leverage step and the one most vendors don’t help you with, because it isn’t in their interest to make leaving easy.

If you own your domain (yourschoolpta.org, or similar) — and you should confirm this before anything else — the migration can point that same domain at the new site with zero URL disruption for anyone who has it bookmarked or Googled it. This is the clean case: nothing breaks, because the address never changes.

If the old vendor owns or controls your domain, that’s the first problem to solve, independent of the migration itself — see the domain-ownership note below. You need the domain transferred to a registrar the PTA controls before you can point it anywhere new.

If your URL structure is changing (new page slugs, a reorganized nav), you need a redirect map: every meaningfully-trafficked old URL pointing to its new equivalent. Pull your old site’s top pages from Google Search Console or Google Analytics if you have access — the calendar page, the donation page, any page with backlinks from the school’s own site or local press. A parent who clicks a two-year-old bookmark and hits a 404 doesn’t retry; they give up and call the office. A 301 redirect costs nothing and prevents that entirely.

Do this step even if it feels like overkill for a small PTA site. The whole point of a website is that people find it without being told where it moved.

2. Migrate the email list — correctly, not just as a CSV dump

Your parent email list is the actual asset here, more than the website itself. Two things have to go right.

Get a clean export before you touch anything. Whatever tool you’re leaving — Mailchimp, Constant Contact, a spreadsheet someone’s been maintaining by hand, or a list baked into the old vendor’s platform — export it in full before you cancel anything. Vendors are not obligated to help you leave gracefully, and “we’ll get you the list after you’ve paid your final invoice” has burned more than one board. Get the export in hand first.

Re-permission carefully if you’re changing sending tools. If parents originally opted in through the old platform and you’re moving to a new email tool, most providers require you to carry forward proof of consent (an import from an existing list generally counts) rather than re-asking everyone to opt in cold — a fresh opt-in blast reads as spam to people who already said yes once and can tank your deliverability. Check your new tool’s import requirements before you migrate the list, not after your first newsletter lands in spam folders.

Separately: if your donation or membership system is tied to the same tool that runs your website (common with all-in-one vendors), confirm donor and member records export too — not just the newsletter list. Losing four years of donor history is a bigger loss than losing four years of blog posts.

3. Carry the calendar forward, with the .ics link intact

The calendar is the page parents actually use week to week, and it’s the one migrations break most often because boards think of it as “content” instead of “infrastructure.”

If parents have subscribed to your calendar’s .ics feed in their phone’s calendar app (Google Calendar, Apple Calendar), that subscription is a URL, not a saved file — if the URL changes, every parent’s synced calendar silently stops updating and nobody notices until they miss an event. Either preserve that exact .ics URL on the new site (possible if you control the domain and structure it deliberately) or send an explicit “resubscribe to the new calendar link” email as part of the launch, not buried in a general announcement.

Recurring events (weekly pickup, monthly board meetings) need to be rebuilt with their recurrence rules, not just as a list of one-off dates — a calendar that shows this month’s meeting but drops the recurrence pattern quietly stops being useful in January.

4. Announce the switch like it’s news, not a footnote

The technical migration can be flawless and you’ll still lose people if nobody tells them it happened. Plan a short communication sequence:

• Two weeks before launch: a heads-up email — “we’re moving to a new website, here’s what’s changing, here’s what isn’t (your bookmarks, your calendar, how you contact us).”
• Launch day: the announcement, with the new link, and an explicit note that the old link still works (because you redirected it) or exactly what to do if it doesn’t.
• Two weeks after: a follow-up for anyone who missed the first two — “in case you haven’t seen it yet.”

This is also the moment to resolve the ownership question publicly and reassuringly: the reason you’re moving, briefly, and confirmation that the PTA — not a vendor — controls the new site going forward.

Who actually owns your PTA’s domain?

Before scheduling anything, answer one question: who actually owns your domain right now? Run a whois lookup (any free whois tool) on your domain and check the registrant. If it’s the vendor’s name, or a generic “Domain Admin” tied to the vendor’s company, your domain isn’t fully yours — even if you’ve been paying for it for years. Getting it transferred to a registrar the PTA controls (Cloudflare, Namecheap, Google Domains’ successor, whichever) needs to happen before the migration, because a vendor who senses you’re leaving has less incentive to cooperate quickly. This single check is worth doing regardless of whether you’re migrating this year — domain lock-in is the silent trap most boards don’t discover until the moment they try to leave. It is the same trap that makes leaving Educational Networks take a 60-day window instead of a weekend.

How long does a PTA website migration take?

For a typical PTA site, this whole sequence fits in about four weeks without rushing anything:

The old vendor is cancellable the same day you launch, since nothing depends on it anymore.

This is close to the exact sequence we run for schools and PTAs switching vendors to us — content migration, redirect mapping, and calendar/list handling are part of the base build, not a separate line item, because a migration that quietly loses parents is worse than not migrating at all.

Bottom line

A PTA website migration loses parents when the URL breaks, the email list doesn’t transfer cleanly, the calendar silently stops syncing, or nobody bothers to announce the change. None of those are hard problems — they’re checklist items that get skipped because “just switch vendors” sounds simpler than it is. Confirm domain ownership first, redirect every URL that changes, export lists and donor records before you cancel anything, carry the calendar’s .ics link forward, and tell people what’s happening before and after launch.

If you’re evaluating a switch and want a second set of eyes on what would actually move (and what genuinely can’t be lost), send us a note. The first call is 20 minutes, free, and covers exactly what your migration would look like — including the parts your current vendor won’t volunteer to help with.

Written by Full Stack Tech NYC. We build custom websites for NYC schools and PTAs, and every migration includes redirect mapping and content transfer from your old vendor. See pricing and process →