What we can transfer
Customer accounts, remaining paid time, supported server and key metadata, plans, portal access, DNS settings, and the customer communication needed for the cutover.
Enterprise migration included
Move your existing VPN service into Flirexa with no separate migration fee
When you purchase Enterprise, our team reviews your current setup, agrees the migration map and cutover plan with you, and performs the standard migration into Flirexa without an additional Flirexa migration charge.
How we protect continuity
We build Flirexa in parallel, verify a representative canary, preserve compatible key and address state where possible, and keep a defined rollback point until the result is confirmed.
What needs separate scope
You provide authorized access and an export from the current system. Third-party hosting or provider fees, custom software development, branded applications, and a new marketing website remain separate work.
Before touching production
Inventory the service customers are using today
The hardest migrations fail because the visible panel was documented but the operating assumptions were not.
Customers and devices
Record active accounts, expiration, plan, device count, protocol, assigned IP, server, and whether a configuration can be replaced without direct support.
Servers and keys
Record public endpoints, subnets, public and private key ownership, protocol parameters, DNS, firewall rules, provider limits, and any route that exists outside the panel.
Commercial state
Record prices, remaining paid time, provider invoice identifiers, promo rules, customer credit, email templates, domains, and support commitments.
Recommended sequence
A migration plan with decision points
Build a parallel installation
Deploy Flirexa on a supported clean server. Configure HTTPS, outbound email, backup storage, plans, payment sandbox or low-value test flow, and monitoring before importing production customers.
Prove one complete customer path
Create a new test customer, purchase or assign access, connect every supported device type, renew, revoke, restore, and open a support request. Fix the workflow before migrating history.
Select a representative canary
Choose a small group that covers the protocols, plans, operating systems, and locations you actually use. Do not choose only the easiest internal account.
Decide key continuity
If an endpoint can preserve compatible WireGuard or AmneziaWG private key and address state, existing profiles may survive. If it cannot, plan an explicit customer configuration replacement.
Cut over with evidence
Move the canary, observe handshakes, support volume, DNS, throughput, payment events, and device refresh. Expand only after the defined success window passes.
Retire the old path last
Keep a time-bounded rollback state, reconcile customer and payment records, verify backups from the new system, then revoke old keys and close obsolete public endpoints.
What Flirexa can help move
Customer records are only one layer
- customers, device slots, expiration, and traffic limits
- supported WireGuard and AmneziaWG server metadata and key material
- subscription plans and remaining access periods
- portal accounts and support workflows when a compatible import exists
- server locations, DNS settings, and generated configurations
- branding and customer-facing legal content for Enterprise
The exact import path depends on the source panel and the quality of its export. A source database dump is not automatically a safe or legally sufficient migration plan.
Canary sizeSmall enough to support manually, broad enough to represent real use
RollbackA documented point before the source is changed, with keys and database state recoverable
CommunicationTell customers what changes, when it changes, and whether a new configuration or app login is required
ReconciliationCompare active access and money-related records before and after cutover
Risk map
What can break and how to reduce the blast radius
| Risk | Typical cause | Control |
|---|---|---|
| Duplicate or conflicting VPN IP | Two allocators or stale imported address metadata | Run the address-integrity audit and repair specific clients before enabling both peers |
| Customers lose connectivity | New server key, endpoint, DNS, or protocol parameters | Reuse compatible key material where authorized or distribute a new configuration before cutover |
| Paid time differs | Time-zone conversion, stale plan records, or partial import | Export and reconcile expiration in UTC; manually review boundary cases |
| Payment is credited twice | Old and new webhook endpoints active together | Define one settlement authority, rotate provider webhook targets deliberately, and reconcile invoice IDs |
| Support becomes unmanageable | All customers moved simultaneously | Canary in waves, prepare one clear customer instruction, and staff the change window |
Questions
Migration decisions to make early
Can Flirexa import any VPN panel automatically?
No universal importer can understand every custom schema, key store, billing rule, and manual edit safely. Start with an inventory of the actual source and design a deterministic mapping.
Can I preserve every existing configuration file?
Only when the target retains the compatible protocol, server key, endpoint expectations, and client address. Otherwise issue and communicate a new configuration.
Should I migrate the database directly?
Not unless a documented importer owns the schema mapping and validation. Direct SQL copying can bypass address allocation, audit records, password handling, provider identifiers, and feature gates.
Can the team migrate my existing VPN service?
Enterprise includes a standard migration into Flirexa at no additional Flirexa migration charge. We first inspect the source, agree the mapping and cutover plan, and identify any custom software or third-party work that falls outside the included migration.