The gist
- Preserve the business requirement before recreating its old implementation.
- Quiet features can have important operational dependencies.
- Define better ways of working while you can still shape the scope.
“Does anyone know why we still have this?” is a useful question to ask before a website migration. It can uncover an essential process nobody has documented, a feature built for a customer you no longer serve or a workaround for a platform limitation that disappeared years ago. On the surface, all three can look equally important.
That’s the trouble with asking for everything you have now on a new platform. You may get a cleaner design and still pay to rebuild the same awkward ways of working. A migration gives you a rare opportunity to question the website as a whole, before old decisions become expensive new requirements.
“We’ve always had it” isn’t much of a brief
Imagine a promotion that needs its own duplicate product page because the current theme can’t display the offer properly. Over time, the workaround becomes familiar: someone copies the page, someone changes the links and someone remembers to take it down. When migration planning starts, that routine can quietly turn into a request for the new site to support duplicate pages.
But the business requirement is to present a promotion clearly. Copying the old routine may be unnecessary if the new theme can handle the offer another way. Until you separate the job from the mechanism, it’s difficult to tell whether a feature belongs in the new build or whether it is something the build should finally make unnecessary.
This conversation works best when it stays practical. Ask what would stop working if the feature disappeared, who would notice and what they would do instead. A clear answer helps protect something valuable. A vague answer tells you where more investigation is needed.
The quiet feature may be doing important work
Not everything useful gets clicked by customers. An unremarkable product field might tell the warehouse how to pack an order, while an export that nobody mentions in a design meeting could be how the retail team reconciles its day. Removing either because it looks untidy would mistake low visibility for low value.
That’s why the people who manage orders and customer questions need a place in the migration conversation. They know which details keep the business moving and which apparently small exceptions consume an afternoon. Their experience can reveal dependencies that won’t appear in a tour of the storefront.

A useful review gives each disputed feature an owner and a reason to exist. You might keep the capability exactly as it is, deliver it differently or agree that it can retire. The point is to make the decision while there is still room to understand it, rather than discovering its purpose when an order gets stuck after launch.
Some changes will also be better left until the new platform is stable. Simplifying a website doesn’t mean redesigning every process at once. Where the consequences are unclear, a deliberate later decision is more useful than a rushed removal made to tidy up the scope.
Your oldest pages may be worth keeping
Content needs the same judgement. An old campaign page may have finished its job, while a buying guide that nobody internally talks about may still answer a question customers ask every week. The age of the page tells you very little about which one deserves a place on the new site.
Look at how people reach the content, what they do next and whether it still helps them. A useful guide may deserve clearer presentation rather than deletion; several overlapping pages may work better as one. If the URL changes, choose a relevant destination and test the redirect so an existing link still leads somewhere worthwhile.
Customer and order records deserve their own decision too. You can retire a feature without throwing away the information behind it. Agree what must remain accessible, where it will live and who needs it before switching off the old platform. A cleaner storefront shouldn’t leave staff unable to answer a straightforward question about a previous purchase.
Make “better” something the team can recognise
By the time you approve the build, the brief should explain more than what the new pages will look like. It should be possible to say that a promotion no longer needs duplicate content, an order no longer needs to be re-entered or a customer can find an answer without calling. Those are outcomes people can recognise and test.
That doesn’t guarantee a smaller project. Sometimes replacing a workaround takes more thought than copying it. But it gives you a sound reason for the investment and a way to judge whether the new website has changed the work, rather than simply changed its appearance.
When you look back after launch, the most satisfying improvement may be the task nobody has to do anymore. It won’t necessarily be featured in the homepage reveal, but your team will notice it every week. That is worth making room for while you still have the chance to decide what comes with you.
We’ve Done This Before
Yaletown Business Improvement Association
A full rebrand and Shopify rebuild that gave Yaletown’s business community a faster, easier home online.
View Case Study
Bailey44
Magento to Shopify Plus migration with multi-location POS setup and Shoprunner integration for a fashion-forward brand.
View Case StudyWhat are you hoping the new site will make easier?
Bring that question into the migration brief. port80 can help you work through what needs to stay, what deserves a rethink and how the new site should support your team.

