School website migration checklist: content, links, and launch

A school website migration moves more than pages. Families may arrive through a bookmark, an old newsletter, a search result, or a QR code printed months ago. Staff need to keep publishing while the new site takes shape.

Use this school website migration checklist to decide what moves, who owns it, and how you will verify that important tasks still work. Add an owner, due date, and evidence link beside each item in your project tracker.

Before choosing the launch date

• Name the decision-makers. Assign a project lead and owners for content, technical work, accessibility review, and launch approval.
• Identify sensitive dates. Account for enrollment deadlines, school openings, board meetings, and other periods when a broken page would have immediate consequences.
• Record access and dependencies. Confirm who controls the domain, DNS, hosting, CMS, analytics, and connected services. Store credentials in the school's approved system.
• Agree on the launch conditions. Define which family tasks must pass, which issues prevent launch, and who can decide to postpone or roll back.

Inventory pages and files

• Collect existing addresses. Include campus sites, landing pages, PDFs, images, and links used in newsletters, signs, and campaigns.
• Label each item. Choose keep, rewrite, merge, or retire. Check retention requirements before removing material.
• Record an owner and review date. Prioritize admissions, calendars, contact details, emergency information, transportation, and current forms.
• Keep the source files. Save editable originals for documents and graphics where available. An exported PDF alone can make later corrections harder.
• Plan language updates. Record which translated pages and documents need to change alongside their source content.

Here is a sample inventory structure. The entries are illustrative:

Plan search and link continuity

• Keep useful addresses where practical. Do not change a stable URL just to make the launch look new.
• Map changed addresses to relevant destinations. Use permanent server redirects, such as 301 or 308, for moved pages. Avoid sending unrelated retired pages to the homepage.
• Handle removals deliberately. If no replacement exists and removal is appropriate, return a real 404 or 410 response with helpful navigation.
• Update links and page signals. Check internal links, canonical URLs, language links, titles, and descriptions against the final addresses.
• Check launch indexing settings. Remove staging-only restrictions from intended public pages and update the sitemap. Retain protection on private material.
• Retain and test redirects. Google recommends keeping redirects for at least a year; useful old family links may need to work longer. Expect possible search fluctuations during a move. Google's site-migration guidance.

Test the tasks families need

• Run an enrollment journey. Use test data to reach the form, correct an error, submit, and check the confirmation and intended staff destination.
• Check essential navigation. Find a school, a calendar date, transportation information, and the right contact on a phone and with a keyboard.
• Review migrated files. Open current documents and confirm their content and accessibility. Use the staff PDF checklist.
• Check connected services. Test event registration, payments where applicable, maps, calendars, portals, and other vendor handoffs in appropriate test environments.
• Test each priority language. Follow translated links through forms and documents. The school translation guide provides review questions.
• Verify measurement. Confirm that important actions are recorded once, test traffic is identified appropriately, and sensitive family information does not enter analytics fields.

Prepare staff and launch

• Practice routine edits. Have actual publishers update a notice, replace a document, and correct a page using their intended roles.
• Set a final content checkpoint. Record edits made on the old site during migration so that none disappear at launch.
• Confirm backup and rollback steps. Record who can restore the previous state and which systems need attention if launch is reversed.
• Verify the public site immediately. Check the correct domain, secure connections, priority redirects, forms, documents, and staff notifications.
• Keep a follow-up log. Review reported problems, broken links, and search coverage after launch. Assign someone to close each issue and record the result.

Decide whether the site is ready

Our recommended launch decision focuses on completed tasks: can families find current information, submit essential forms, and get help when needed? Can staff maintain those pages? Are known barriers and follow-up actions documented?

Set those expectations before launch day. Then the decision can rely on evidence your school has agreed to collect.

Explore EdPilotHub's school website design offering and CMS, or contact our team to discuss your migration scope.