When large companies refactor internal systems, frontend work should not be treated as page outsourcing

The expensive frontend work in internal systems is rarely the number of pages alone. A purchase request, quotation, or work order may include draft, submitted, rejected, cancelled, additional-information, and re-approval states. Each state changes visible fields, editable fields, and available actions.

If these rules are scattered across page-level conditions, the first version may work but maintenance becomes difficult. A safer approach separates state, permission, validation, and feedback rules in the frontend architecture so interface behavior has clear ownership and can stay aligned with backend rules.

I would not make React, Vue, or a component library the center of the refactor decision. The more important questions are whether interface state is traceable, components are reusable, and tables, filters, permissions, dialogs, imports, and exports follow consistent patterns.

As the system grows, a frontend without engineering boundaries makes every small change risky. Adding one field may touch several pages; changing one permission hint may affect multiple roles. A modern frontend architecture should reduce that fear instead of only making the screens look newer.

Many legacy systems cannot and should not be replaced in one pass. A more controlled path is to choose one frequent workflow with clear pain and manageable dependencies, then complete the full loop: list, detail, edit, approval, exception feedback, and operation history.

That loop exposes real constraints: whether old APIs are enough, whether permission rules are clear, whether users accept the new interaction, and whether backend status fields need improvement. Once this section is stable, expansion becomes safer than building a large new shell first.

If a system is used rarely, has simple workflows, and is maintained by a few administrators, full frontend refactoring may not be worth the cost. Fixing visible usability problems, logs, and permissions may be a better investment.

But when a system is used daily by many people, with complex forms, multiple roles, frequent exceptions, and high training cost, the frontend is no longer a cosmetic layer. It directly affects whether business rules are executed reliably and whether future maintenance requires rediscovering the logic every time.