#Existing V7 user migration

Target conceptual flow

Existing V7 userV8 accountExisting organizationsExisting serversExisting planExisting subscriptionExisting usageV8 dashboard

#What is decided V8 requirement

V7 users log in with the same email and password, and keep 2FA, IP whitelist and Google/GitHub login.
Profile, email preferences, delete protection, 2FA, Google Authenticator, IP whitelist, login history, notification channels and API tokens carry over. V7 API tokens keep working after the move, so scripts using them must not break (backend doc 3.13 + "existing users", 2026-10-03). Notification channels include the V7 Discord and Webhook types, which V8 now supports (3.15).
Only account-level data moves (users, billing, account-related data such as teams and security settings). V7's server/app tables are not recreated.

#Mapping table

Area	V7 source	V8 target	Status / risk
Account	`users` (email, bcrypt password, status, 2FA flags, google2fa secret, timezone, preferences)	V8 users	Passwords: both are Laravel bcrypt, so they can be copied Assumption. Statuses (`not_active`, locked, banned) need mapping. Deleted users (`deleted_users`) excluded? Open question
Social logins	`user_providers` (google/github)	V8 linked accounts	V8 requirement keep
2FA / backup codes / IP whitelist	`two_fa_backup_codes`, `whitelist_ips`	V8 equivalents (encrypted)	V8 requirement keep
Organizations	`organizations` (+ `main`, logo, SSH key pair)	V8 organizations	SSH key pair not needed (OSS) Assumption
Members / invitations	`organization_members`, `member_role`	V8 members	Pending invitations: carry over or drop? Open question
Roles / permissions	`organization_roles`, `permission_role` (boolean, ~92 V7 permission names)	V8 roles with none/view/manage	Permission names differ (V7 `server.firewall` vs OSS `firewall`/`app_*`). A mapping table is needed. Granted → manage Assumption D-7
Shared-server members	`organization_members.server_id`	?	Depends on D-8
Servers	`servers` (agent-based, ~40 columns incl. root/DB passwords)	V8 server link	Not migratable as data. A V7 server becomes manageable by V8 only after OSS is installed on it and its Central key is linked. The OSS team is making OSS behave like V7 on V7 servers (commit `5b4e01e9`: "Many v7 servers will move to v8"), and OSS Server Sync adopts existing sites, databases and workers. But installing OSS on a live V7 server is not documented or tested Open question D-19
Applications / databases / backups	V7 tables	Stay on the server (OSS adopts through Sync)	Not moved to Central (R5)
Plan	`new_subscription_plans` (tier, cycle, price, limits, `expires_in_days`), old `subscription_plans`/`subscriptions` (server-based), lifetime, lifetime installments, free-forever and per-user custom plans	V8 subscription	Phase 7 (2026-10-05) settled most of it V8 requirement: users keep plan, cycle and days left, and V7's days-left counter becomes a real expiry date (7.25), so migrated and new plans show the same thing; lifetime owners keep theirs including those mid-installment (V7: 1 or 3 payments) though how installments work in V8 is parked; legacy per-server plans keep working with a convert option; V7's free forever (7.21) and per-user custom plans (7.20) both exist in V8, so they have a target. Still needs the plan catalog Open question D-4
"Restructured" users	V7 showed them only Newbie (as "Managed") and Business (as "Self Managed")	Two real plans, "Managed" and "Self Managed", each with its own name, price and features, visible only to them	Decided 2026-10-05 (7.14) V8 requirement. Every other user sees the one common catalogue, so this is the only per-account plan list. Nothing to build on the frontend — the plans page just renders what the API returns for the account
Usage	Counted from servers/apps	Recomputed in V8	Can't be computed until servers are linked
Wallet / credits	`users.credits`, `free_credits`, `server_credits`	V8 wallet	Decided by Phase 6 (2026-10-05) V8 requirement: paid, free and active promo credits carry over, and `server_credits` is dropped — the leftover is added to paid credits, "so nobody loses money". Still needs reconciliation + a sign-off report Open question
Billing history	`transactions`, `wallet_histories`, `charges`, `invoices`	V8 billing (read-only history)	Transactions, receipts and charges carry over (Phase 6 existing users) V8 requirement. Phase 6 says receipt and not invoice, so whether V7 invoice records keep that name is unstated Open question
Payment methods	Stripe customer/cards, auto-recharge	V8	Saved Stripe cards, auto-recharge and the reminder setting carry over (Phase 6) V8 requirement, so the forms must open pre-filled. Stripe customer ids can be reused if the same Stripe account is used Assumption
Billing details	`user_billing_details` / organization billing details	V8 account billing details	Carry over (Phase 6) V8 requirement. Phase 6 stores them on the account that pays (6.2), so V7's organization-level details need a target Open question
Managed servers	Managed/premium servers + their hourly charges	V8 managed servers	Carry over with their charges (Phase 6) V8 requirement. A migrated managed server already has hours used this month, so the usage screen must not assume it started in V8
Audit	`activities` (English sentences)	V8 audit	Import as "legacy" entries or leave in V7 (read-only) Open question
Notification channels	`notification_channels`	V8 channels	V8 requirement keep. All V7 types are supported in V8 after 2026-10-03 (Email, Telegram, Pushover, Slack, Discord, Webhook), so no channel is dropped at migration
API tokens	V7 personal API token (6-month personal access token)	V8 personal API token	V8 requirement Migrated and kept working (2026-10-03). The Account → API screen therefore shows an existing token instead of offering to create one (3.13)
Blueprints	`wordpress_blueprints`	V8 blueprints	Simple copy. Owner model D-14
Affiliate / referral	referral codes, clicks, referrals, Tolt codes	—	In scope — backend Phase 18 (2026-10-08) V8 requirement. Referral codes, clicks and referrals (*approved and* pending) carry over, and a pending referral can still earn the referrer their credit. Tolt codes carry over and affiliates keep working in Tolt. The old built-in affiliate data is not migrated** — it moved to Tolt in 2024
Support	many tables	—	Not in V8 (decided 2026-10-08) — nothing to migrate
White label / self-hosted	many tables	—	In scope — backend Phases 12 and 15

#Migration failures to plan for

Failure	Handling
Duplicate email already registered in V8	Merge rules or block Open question
V7 user without a verified email	Migrate as unverified and require verification
Organization owner deleted / banned	Skip or reassign Open question
Expired or negative-balance accounts	Migrate with state, show "pay balance"
Permission names with no V8 equivalent	Drop, with a report
Server can't get OSS (unsupported OS, conflicts)	Stays on V7 until fixed: V7 and V8 run in parallel? Open question
Partial migration run	Idempotent, resumable batches with a per-user status

#Compatibility problems found

Subscription ownership: V7 is per user, while the request is per organization (D-3).
Permission model: boolean vs none/view/manage, and different names (D-7).
Servers: the V7 agent vs OSS. There's no data path, only "install OSS and link".
Plan constants are hard-coded in V7. V8 needs them as data before mapping.
Lifetime deals keep working, but installments are parked (2026-10-05), so a migrated owner can be mid-installment with no V8 flow to finish paying. Legacy server-based plans keep working with a convert option.
Server credits exist in V7 and not in V8. Phase 6 folds the leftover into paid credits, which is the simple answer, but the wallet screen then shows a bigger paid balance than V7 did — the migration report has to explain it.
English-only activity text can't be translated after import.

#Required before migration can be designed

Plan catalog + subscription model decided (D-3, D-4).
~~Permission mapping table (D-7).~~ Specified 2026-10-08 (Phase 4, Existing users): all 92 V7 organization permissions map onto the new keys, a role gains a key if it had any V7 permission mapping to it, and where V7 was finer (phpmyadmin → server.database.manage, wp-login → application.manage) the role gets the broader key — never less access. New V8-only keys go to roles that had manage on the parent area. V7 support and site-migration have no key. A migration report lists the widened cases — but no screen is named for reading it Open question. See FE: Permissions & role matrix.
Admin permissions map too — specified 2026-10-08 (Phase 17, Existing users). A V7 list / panel permission becomes view, a create / update / delete / status action becomes manage: user-list / user-panel / account → Users (view), user-status / create / user-account-delete → Users (manage), and the same split for transactions, charges, promo codes, DNS, organizations and deleted servers; user-account-login → Login as user, role-permissions → Admin roles & permissions. No admin loses access — and unlike the organization side, nothing has to be widened, because V7's admin permissions were already action-shaped, so they split cleanly. Admins holding several V7 roles get one combined role, listed in a second migration report. See FE: Admin panel.
An OSS-on-V7-server install path, tested on a copy of a real V7 server (D-19).
A cut-over plan: big bang vs per-user opt-in, and whether V7 stays read-only.