bloomz 
Part of our guide to choosing a district website platform.
District website migrations rarely fail for technical reasons. They fail because nobody wrote down what “done” looks like before the work started. Pages get missed, old links break, the new site launches half-accessible, and three months later staff are still copying content over by hand. A migration without a plan is just a slow accident.
A plan, by contrast, is mostly a checklist. Here is a practical one, organized in the order the work actually happens.
Before the move: inventory and plan
Inventory your content
You cannot migrate what you have not counted. Start with a full inventory of the existing site: every page, every PDF, every form, every embedded calendar and directory. Note which pages get real traffic and which are dead weight. Most district sites are carrying years of stale content, and a migration is the moment to leave it behind rather than haul it forward. Flag the high-value, high-traffic pages, because those are the ones whose URLs you will need to protect.
Map redirects to protect SEO
This is the step that gets skipped and causes the most pain. When URLs change, every old link, every bookmark, every search-engine result, and every reference from another site points at a page that no longer exists. Parents land on a 404. Your search ranking drops. The fix is a redirect map: a list pairing each old URL with its new home, so visitors and search engines are sent to the right place automatically. Build this map during inventory, not after launch, when the old URLs may already be gone.
Set the timeline honestly
Decide up front what the schedule is and who owns each piece. A realistic timeline names a launch target, a content-freeze date on the old site, a window for testing, and a go-live plan. Vague timelines are how a “few weeks” migration becomes a six-month project.
During the move: build, verify, test
Verify accessibility as you build
Accessibility is far cheaper to get right during the build than to retrofit after launch. As pages are created, confirm the basics hold: images have alt text, color contrast meets the standard, every control is reachable by keyboard, and headings are structured for screen readers. Replace inaccessible PDFs with real web pages where you can. Building on a platform that is WCAG-ready and keyboard-navigable by default removes most of this burden, because the baseline is already in place rather than something you bolt on at the end. We go deeper on the requirements in school website accessibility: meeting WCAG and ADA.
Test before anyone else sees it
Walk the redirect map and confirm old URLs land where they should. Check the site on phones, not just desktops, since most families visit on mobile. Confirm forms submit, calendars display, and the staff directory shows current people. Have a few staff outside the project click around and report what breaks.
After the move: launch and keep it current
Train staff before launch, not after
A new platform that nobody knows how to use produces a site that goes stale immediately. Train the people who will actually post content, the front-office staff and building communicators, before go-live. Keep it short and task-focused: how to post an announcement, add a calendar event, update a page, embed a form. The goal is that publishing on the new site feels easier than the old one, so people actually do it.
Decide who keeps it current
Name the owners. Migration teams obsess over launch day and forget that the site has to stay alive afterward. Decide who is responsible for each section and what the routine is for updates. A site with no named maintainers drifts out of date within a semester, and you are back where you started.
Why migrations balloon, and how to keep them short
Migrations stretch for a few predictable reasons. Teams try to recreate every page rather than pruning. Redirects get treated as an afterthought, then become an emergency. Accessibility gets deferred to “phase two” that never arrives. And content has to be rebuilt from scratch in the new system, page by page.
That last point is where the platform choice matters most. If the new website runs on the same engine as your family communication, a large share of the content is fed automatically rather than rebuilt by hand. The announcements, the calendars, the SIS-synced staff directory, and the forms you already publish to families flow onto the public site, so there is far less net-new content to recreate. The migration shrinks because most of what would have been manual data entry is already populated by the work your staff does every day.
Bloomz Slick Sites is built on that model, and it is the single biggest reason a district move can stay measured in weeks instead of seasons. We cover the cost side of the same decision in cutting school website hosting costs without cutting quality.
A migration is only as smooth as the checklist behind it. Inventory honestly, protect your URLs, build accessibility in, train your people, and name your maintainers, and the move stops being something to dread. To see how Bloomz keeps the migration short and the new site self-sustaining, Schedule a demo.