The migration, step by step
From inventory
to production.
Six stages, from a read-only inventory to the live application and handover.
- 01
Inventory the whole site
Map every page, feature, dataset, account flow and integration.
Read-only inventory - 02
Approve the migration plan
Review the scope, architecture, costs, data move and recovery plan. The agent waits here.
Your approval - 03
Rebuild the application
Implement the frontend and Motoko backend, with real workflows and permissions.
Working application - 04
Move and reconcile the data
Rehearse imports. Check records, files and relationships.
Verified data - 05
Reconnect existing users
Link legacy accounts to Internet Identity with verified proof. Test roles, sign-in and recovery.
Verified account access - 06
Approve cutover and verify
Complete the approved cutover and test the real site, including recovery.
Live site + handover
Migration details
Every part
of your site.
Pages, business rules, data and accounts all belong in the plan. Explore the scope and a code example.
The scope below shows a frontend and backend on ICP. With hybrid hosting, the frontend stays with your provider.
What moves to ICPPages · logic · data · files · accounts · jobs · domain
Showing all 7 migration components
| What you have | What it becomes | What your agent verifies |
|---|---|---|
| 01 Pages & templates | A built frontend served as certified assets. | Content, URLs, SEO, redirects, accessibility, and search. |
| 02 PHP code & plugins | Motoko canisters with explicit application interfaces. | Business rules, forms, permissions, integrations, and plugin replacements. |
| 03 Database | Persistent application state with a deliberate data model. | Imported IDs, relations, constraints, totals, and recovery. |
| 04 Uploads & documents | Certified assets or a file-storage design sized for the site. | File hashes, links, access rules, capacity, and running costs. |
| 05 Logins & user accounts | Internet Identity with verified legacy-account linking. | Existing users, ownership, roles, recovery, and the transition plan. |
| 06 Scheduled jobs | Canister timers and durable coordination where appropriate. | Retries, duplicate handling, external services, and behavior after upgrades. |
| 07 Your domain name | The same custom domain pointing at the new ICP site. | Authorized DNS changes, TLS, paths, redirects, and identity origins. |
Keep your domain and established URLs. Your team approves the DNS change and verifies the new site before cutover. How custom domains work ↗
PHP and Motoko, side by sideA signed-in note, saved with persistent state.
save.php<?php
session_start();
if (!isset($_SESSION['user_id'])) {
http_response_code(401);
exit;
}
// Assumes a configured PDO connection.
$stmt = $pdo->prepare(
'REPLACE INTO notes (user_id, body) VALUES (?, ?)'
);
$stmt->execute([
$_SESSION['user_id'], $_POST['body']
]);
MOTOKO main.moimport Map "mo:core/Map";
import Principal "mo:core/Principal";
persistent actor Notes {
let notes = Map.empty<Principal, Text>();
public shared ({ caller }) func save(body : Text) : async Bool {
if (caller.isAnonymous()) return false;
notes.add(caller, body);
true
};
};Illustrative signed-in note example. The PHP route assumes a configured database and protected POST handling. Production code needs suitable input limits, permissions and account recovery. Motoko example type-checked with moc 1.14.0 and core 2.6.2.
Current Motoko actor syntax ↗Start with the inventory
Start with your
PHP project.
Open your codebase, copy the brief and review the migration plan.