Modernize a working customer portal
Change the technology without losing the customer records and rules that make the portal useful.
What is difficult today?
An established portal still serves customers, but changes are difficult. Its original assumptions may live in old code and a few employees’ memory. A new interface alone does not address runtime compatibility, data relationships or the permissions protecting customer documents.
Forge’s modernization Project begins with authorized discovery and a preserved baseline. The owner approves the important rules and the required depth of change. A candidate version is verified against those rules before a separate cutover decision.
A sequence with accountable decisions.
The owner defines the target. The engineering work keeps the relevant business rules and returns evidence at each acceptance boundary.
Authorize the source scope
Identify exact code roots, data sample and read permissions.
Capture a baseline
Keep source, dates and sensitive settings separate.
Choose the modernization path
Upgrade or refactor where justified; document preserved behavior.
Build and rehearse
Verify document access, data mapping and important routes.
Approve data-aware cutover
Reconcile later writes and verify the deployment target.
Data, rules and proof—not only screens.
Data involved
- Runtime and dependency manifests; schema and minimized sample.
- Important public URLs and private document relationships.
Rules to preserve
- Preserve the agreed customer boundary.
- Do not send real mail or payments in preview.
- Do not replace production with an outdated database copy.
Evidence to inspect
- Compare representative record relationships.
- Check original and replacement URLs.
- Reject unauthorized document downloads.
- Rehearse rollback with the write timeline.
Owner decisions
- Which old behaviors are defects, not requirements?
- What transition window can the business accept?
Preserve the contract while changing the implementation
Inventory the live application before choosing a rewrite. Note its routes, database relationships, scheduled jobs, file storage and external connections. Import only the authorized scope into an isolated environment. Production can continue changing while that copy is being modernized, so the first database snapshot is not the final deployment dataset. A cutover plan must account for records created after import.
Use the owner’s examples to distinguish essential behavior from accidental legacy behavior. A hidden permission bug is not a feature to preserve. The Project should identify intentional differences, retained routes and required tests. Rehearsal compares the candidate against those rules and makes unavailable external checks visible. When a release is accepted, choose the original server, a supported new destination or Yepsy hosting. Verify configuration and data movement separately; source access never silently becomes permission to write to production.
Follow a related example from start to release.
A worked example showing decisions, implementation and verification.
The video could not be loaded. Try again later.
Prepare the next decision.
Upgrade, refactor or rewrite? Start with the failure you need to remove
Choose the smallest change that resolves the actual constraint while preserving important behavior.
Read the guide →What to inventory before importing a legacy application
Prepare source, database, runtime and integration information without turning an import into a production change.
Read the guide →Plan a database cutover without forgetting new production orders
The database you imported last week is not the database your customers are using today.
Read the guide →Start with a product.
Keep building a business.
Bring an idea or the software you already own. Give the next improvement a clear path from intent to evidence.