For the services people depend on

Public purpose. Business continuity.

For public websites, customer portals and business applications. Start with the requirements and workflows your service needs to preserve.

Different services. Shared decisions.

01 / Public sector & institutions

Public information.
Essential services.

Government websites, university content and service forms. Plan for accessible pages, stable links and publishing permissions. Include procurement and data-protection requirements.

Public information
Documents & archives
Editorial workflows

See the migration approach

02 / Companies & engineering teams

Customer services.
Business systems.

Company sites, customer portals and custom PHP applications. Map the business rules, account access and integrations that must keep working.

Content & commerce
Customer accounts
APIs & scheduled jobs

Brief your developer or agent

Choose one service to evaluate.

Give the migration a clear boundary: a public information site, an application form or a customer portal. List the journeys people rely on and the systems each one touches.

Public sector: include accessibility, records retention, procurement and data-protection requirements.
Business teams: include account access, transactions, reporting and integrations that support daily operations.

Treat plugins as feature decisions.

An export can move content without recreating everything the original application does. Give every plugin, module and custom extension an explicit destination: rebuild the feature, keep an external service, replace it or retire it.

Name the critical behaviors, such as form delivery, search, checkout, translations and publishing permissions.
Agree how each behavior will be tested, including failed requests and denied access.

Make ownership part of the plan.

Identify who can confirm the content, reconcile the data and accept the application’s behavior. Assign ongoing ownership for access, upgrades, funding and monitoring.

Rehearse the move with representative data before changing production traffic.
Keep the previous service available until the agreed checks and recovery plan are complete.

More than the homepage

Map your
migration.

Decide what moves and how it will be checked, from public pages and accounts to data and external systems.

See the seven-part migration mapPages, logic, data, files, access, integrations & URLs

Example migration map: existing components, possible destinations and verification.
Existing component	Target in the agreed scope	Verification
Pages & URLs	Rebuilt frontend on ICP, or on your current host	Check content, accessibility, routes and redirects.
PHP logic	Motoko methods for the selected backend features	Test business rules, permissions and error handling.
Database	Motoko canister state for data included in the move	Reconcile records, relationships and update behavior.
Files & uploads	ICP storage or retained storage, according to data requirements	Check file counts, integrity, access and upload limits.
Accounts & roles	Reviewed sign-in, verified account linking and explicit permissions	Test user and administrator journeys, including denied access.
Jobs & integrations	Motoko timers or retained services, with reviewed interfaces	Check schedules, failures, retries and external dependencies.
Domain & routing	Your domain with routing matched to the chosen architecture	Check DNS, certificates and important links before cutover.

A full move can include the frontend and backend. A hybrid move keeps the frontend on its current host. Plugins, integrations and retained services require their own review; they do not transfer automatically.