Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Recently, at an Arch Tea Time and at a Consumer Review, questions were raised on tradeoffs and decisions on when to rewrite legacy frontend pages to MFE technology.


The following set of recommendations can be used as a basis for discussion by the owning squad. As with other implementation decisions, consider tradeoffs between schedule, budget, and resources, along with code quality as defined below.

New large-scale frontend development


For a minimal required change, the team will likely not invest in an entire re-write effort.


‘Medium effort’ changes

For a more substantial change, here are a few options that the owning squad can consider given other business considerations.

  • Option 1 Rewrite: Invest in a complete rewrite if this is a “core” functionality of the platform and the business expects to innovate further in this area.

  • Option 2 Stepping Transition: A middle-ground approach is to use ReactRenderer to embed new React code into legacy code. Implementing the newer code in the latest supported technology is a good transitory stepping stone in anticipation of a future rewrite.

    • The new React code can be implemented as its own separated “nano-FE” code that is included into the legacy FE code.

  • Option 3 Stick with Legacy: The team can decide to simply stick with the legacy frontend code for now, especially if the required change is in a part of the frontend experience that

    1. is expected to be deleted (see DEPR board).

    2. is scheduled to be rewritten within the next year (see MFE Rewrite Roadmap (work-in-progress)).

    3. is not critical to business operations and not expected to be updated with feature changes in the next 2 years.


  • For MFE rewrites, see Definition of Done for an MFE Rewrite.

  • For legacy frontend updates that are somewhat temporary (e.g., #1 and #2 in Option 3 above), the team may choose to not invest as much time on otherwise “Clean Code” practices - with the caveat that the team create a backlog reminder to remove any “hack” code within (3) months. Adding a TODO statement in the code along with a link to a Jira ticket is one way of tracking this.