Start with authority and location
Confirm who can authorize access to the source and which application roots are in scope. A server may host several unrelated sites. Record the exact target and use a connection with only the access needed for discovery. Read access for import is not permission to alter the live application, restart services or change DNS. Keep those decisions distinct even when one person owns the server.
Inventory what the code depends on
Collect framework and dependency manifests, runtime versions, database engine and required extensions. Include background workers, schedules, file storage and external services. Environment variables may contain secrets, so extract the configuration meaning without copying raw credentials into a planning document. A useful inventory tells the team which capability a setting provides rather than publishing its sensitive value.
Decide how much data is necessary
A schema and a carefully designed sample can be more useful than an unbounded production copy. Identify the records required to test important behavior and the data that should be removed or transformed. Estimate storage before import, including attachments and duplicate snapshots. The right sample preserves relationships and edge cases without needlessly exposing every customer record.
Preserve a read-only baseline
Keep the imported original separate from the editable candidate. Record when it was captured and what was excluded. The source may continue receiving orders while modernization proceeds. Before cutover, the team must reconcile later production changes rather than deploy an old database snapshot over current records. Forge treats import, preview and deployment as different stages of the same controlled lifecycle.
Inventory the real application, not only the repository
A legacy portal may rely on uploaded files, scheduled scripts, a database extension and credentials stored outside the code directory. A repository clone alone will not reproduce it. Before import, identify the application root, public web root, data directories, database engines, runtime versions and external dependencies.
Estimate the storage required for an immutable original, a working copy and a test dataset. Use schema-only or a minimized authorized sample when full customer records are not necessary. Secret discovery should produce protected references and a redacted configuration map, not paste credentials into an AI prompt.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Source | An exact authorized root and revision. | Inventory with hashes and exclusions. |
| Data | A permitted dataset and file scope. | Export manifest and minimization decision. |
| Runtime | Web, CLI and scheduled jobs are understood. | A reproducible baseline start. |
Where this goes wrong
An import credential is not deployment permission. Avoid treating access to a shared hosting account as permission to inspect neighboring sites. Large archives, symbolic links and unexpected network destinations need bounded handling before any unfamiliar code is executed.
A good import creates a trustworthy starting point, not a copy of every secret on the host.
Turn it into a working checklist
- Confirm exact roots and read permission.
- Record runtime, jobs and storage.
- Minimize and size the data sample.
- Preserve baseline and capture date.
A concrete next step
Hand the Architect an application map, a storage estimate, a redacted environment contract and a list of known working journeys. Keep unknowns explicit: an unobserved scheduled task is not a task proved unnecessary.
Watch a related case
The video could not be loaded. Try again later.