Comparing the Old Site and the New Site Screen by Screen
When an organization's website moves to a new platform, the hardest problems are often the smallest ones. A missing icon in the footer. A paragraph that lost its bold text. A gallery that shows four images instead of six. A menu that works on desktop but disappears on a phone. Nobody notices them in a quick look, and every one of them makes the new site feel slightly wrong.
That is why comparison is a formal step in how we move websites, not a casual glance at the end. Here is how we do it.
Compare at real sizes
We capture the old site and the new site at the same viewport sizes: a common desktop size and a common phone size. Comparing at exactly the same dimensions makes differences easier to spot, because layout changes cannot hide behind a different window size.
The phone comparison is especially important. Many sites were designed for desktop and have mobile layouts that hide, rearrange or simplify content. Some even serve a separate mobile version. An importer that handles only the desktop layout can produce a site that looks right on a laptop and wrong on a phone.
Page by page, section by section
For each important page, we compare from top to bottom: header, hero, each section, footer. We look for:
- Missing or extra sections
- Text differences, including formatting like bold, italics and links
- Image differences: missing images, wrong crops or wrong sizes
- Font and color differences
- Spacing and alignment problems
- Overflowing text or content that scrolls sideways on phones
- Interactive elements that do not work, such as menus, sliders and accordions
Evidence is saved for each run
Every comparison run saves its screenshots and findings in a folder for that run. That gives us a record of what each attempt looked like and makes it easy to see whether a fix improved things or introduced a new problem. When a client asks why something looks different, we can show exactly what changed between runs.
Fix the cause, then run again
When a comparison finds a difference, we look for its cause in the importer rather than fixing the page by hand. If a particular kind of gallery imports incorrectly, every site with that gallery will have the same problem. Fixing the importer solves it for all of them.
After the fix, we take a fresh backup and run the import again from the beginning, then compare again. The loop continues until the comparison is clean. You can read about the full process in how we rehearse a website migration.
Automated checks support visual review
Some checks are better done by machines. After an import, automated checks confirm that pages load successfully, that no images or files still load from the old host, that the sitemap lists the right pages and that no page overflows horizontally on phones. Those checks catch what eyes miss, while visual comparison catches what machines cannot judge, like whether a layout still feels right.
Interactive behavior counts
Some differences only appear when you interact. A "back to top" button that should appear on scroll. A video that should only load when played. A mobile menu that should open and close. We test those behaviors on the new site at both sizes, because a page that looks identical but behaves differently is not a faithful move.
Real editing is part of the test
A migrated page should not only look right; it should be editable. As part of verification, we open migrated pages in the visual builder, make a small text or image change, save, check the live page and then restore the original. If editing breaks the layout, the migration is not done.
The bar for done
We consider a rehearsal successful when every important page matches at desktop and phone sizes, editing works, automated checks are clean and the evidence is saved. Even then, the real move waits for the owner's approval and the remaining steps, like form delivery checks and the domain switch.
Two related habits make comparisons trustworthy: our importers never hotlink, and every run starts from a verified backup.
Frequently asked questions
How do I check that my website migration worked?
Compare the old and new sites page by page at the same desktop and phone sizes, test interactive elements and confirm pages can still be edited.
Why compare on phones separately?
Many sites show different layouts or content on phones. Comparing only desktop views can miss problems mobile visitors will see.
What if the new site looks different from the old one?
Find the cause, ideally in the import process rather than the individual page, fix it and run the import again to confirm.
Related Posts
Checking Every Screen at Phone Width
Many people manage their organizations from a phone. Here is why we check every screen at phone width, what usually breaks and how we fix it before customers notice.
Why Every Import Starts With an Automatic Backup
Imports change a lot of data at once, so we never start one without a verified recovery point. Here is how the automatic backup step works and why it is not optional.
Turning Fixed Bugs Into Regression Checks
The best time to stop a bug from coming back is right after you fix it. Here is how we turn fixes into checks and what we learn from each one.
Accessible Forms: Labels, Errors and Focus
Forms are where people sign up, pay, register and ask for help. Here is how we make them clear and usable for everyone, including people using screen readers or keyboards.
Background Jobs That Remember Whose Work They Are Doing
Slow work like sending email or resizing images happens in the background, long after the request ends. Here is how our jobs carry the right customer with them.
Comments (0)
No comments yet. Be the first to share your thoughts!