A store redesign can become the container for every deferred technical decision. The theme needs work, the runtime needs updating and several extensions no longer have a clear owner. Combining all of that into one promised launch makes it difficult to see which work protects the existing business and which work creates a new experience.

Give the platform its own plan

Magento 2.4.9 was released on May 12. Its versioned Composer manifest declares PHP ranges for 8.3, 8.4 and 8.5. That is a concrete starting point for a compatibility assessment, rather than evidence that an existing store and every extension are ready to switch.

Map the current runtime, services and installed modules against the intended target. Keep that assessment separate from the visual wish list. A business owner should be able to understand the platform work even if the storefront design has not yet been approved.

Decide what the store still needs

An extension installed years ago may represent an important business rule, a workaround that is no longer needed or a feature nobody uses. Identify which case applies before carrying it into the next version. This is a chance to reduce ambiguity, not merely update a package list.

Imagine a retailer with two modules affecting delivery charges. Staff know the final total looks right but cannot explain which rule takes precedence. Clarifying that relationship has value regardless of the redesign. It also gives the new checkout a reliable behaviour to present.

Keep two project decisions visible: Supported runtime and services; Compatible store extensions; Stable commerce behaviour; Separate storefront improvements
A platform upgrade and a redesigned shopping experience can support one another without becoming the same scope.

Make customer-facing scope explicit

A runtime upgrade does not automatically create better product navigation or a clearer basket. Those improvements need their own requirements and evidence. Equally, a polished frontend should not hide an unsupported or poorly understood commerce foundation.

Plan a small set of customer-facing changes whose purpose can be explained. A better variant selector or clearer order history may be more valuable than replacing every screen at once. Keep the dependency between those features and the platform work visible.

Use milestones that reveal progress

A successful installation is one milestone. A compatible extension set, verified commerce behaviour and an accepted storefront experience are others. Separate milestones let the team discuss real progress without treating an attractive homepage as proof that the whole upgrade is complete.

The benefit of a new platform release is the opportunity to establish a clearer foundation. With that work visible, design ambition can be assessed on its own merits. The store can move forward with both a maintainable platform and a customer experience shaped by actual shopping needs.