To avoid double billing during a WHMCS migration, assign one system to each customer's next service period. Record the last old-system invoice, the first new renewal and any payment already queued before activating replacement billing. Moving customer records does not transfer billing responsibility or stop an existing payment agreement.
This guide is for hosting providers moving recurring client billing into a new portal while keeping some hosting automation. It focuses on the handover date. For the broader data and module inventory, use the WHMCS migration checklist. The worksheet below is a manual planning tool, not an automatic WHMCS importer.
What can create a duplicate charge during a WHMCS migration?
A duplicate can come from overlapping invoices, two independent recurring agreements, or a retry whose result has not yet arrived. The important question is which system can still request money for the same service period. A successful export does not answer that question.
WHMCS billing logic documents invoice generation, due dates and automatic payment attempts. Review the installed version and your settings before selecting the handover date. An invoice may already exist for a future period even when the customer has not reached its renewal day.
Distinguish an invoice from a payment attempt. Two invoices do not prove two successful charges, and one visible invoice does not prove only one system can collect. Check both billing applications and the provider's actual transaction state. Pending collection, completed payment and failed payment each require a different next action.
External recurring agreements deserve their own check. WHMCS describes optional gateway subscription management for recurring arrangements processed outside WHMCS. Module support and settings matter. Do not assume that changing a service record automatically cancels every provider-side agreement.
Also list reminders, retries and suspension jobs. Even when only one system collects, both may email the customer or initiate an overdue-service action. A handover that prevents duplicate money movement can still confuse customers if two different portals describe different balances.
Build one renewal handover record per service
Use one row for each recurring service, rather than one row for a whole customer account. Hosting, maintenance and a domain renewal may have different dates and responsibilities. Shared contact details are useful for matching identity, but they do not make the services interchangeable.
Download the renewal handover CSV. It contains English column headings and fictional sample rows. Replace the examples in your private copy. It is not an import format for either platform and does not contain payment credentials.
| Field | Fictional example | Check before activation |
|---|---|---|
| Customer and service reference | Example A / managed hosting | Match the actual service, not just an email |
| Paid-through date | 31 October 2026 | Confirm the period on the completed invoice |
| Last old-system invoice | October hosting invoice | Separate paid, unpaid and disputed balances |
| First new service period | 1–30 November 2026 | Ensure this period has no other billing owner |
| First new billing date | 1 November 2026 | Review provider timing and pending attempts |
| Automatic payment readiness | To be confirmed | Verify authorization before collection |
| Hosting lifecycle owner | Existing hosting workflow | Define who handles failure and cancellation |
Add amount, currency, tax treatment and the person responsible for approving the row. These fields prevent a migration that is correct on dates but wrong on totals. An annual hosting agreement billed monthly also needs its actual contractual and service-period information recorded separately.
Preserve historical invoice references. Replacing a portal should not erase the evidence of what was billed and paid. Decide where customers can retrieve old documents and how staff will answer questions about periods that belong to the previous system.
Reconcile existing invoices before starting replacement billing
Start with a small group whose records you can review individually. Separate unpaid historical debt from the next renewal. Bringing an outstanding balance into a new portal and creating a new charge for the same balance is not a reconciliation method.
For each customer, compare the old invoice, provider transaction and service period. Record credits and refunds separately. A credit balance may offset the next invoice; transferring only the gross recurring price can lose that relationship. Have the responsible billing person decide how the balance is carried forward.
Check invoice generation windows, not only due dates. If an old renewal invoice has already been issued, decide whether that invoice remains the collectible document or needs an appropriate correction. Follow your accounting process and applicable requirements instead of deleting records merely to make the new dashboard look clean.
Before changing a pending attempt, obtain its current status from the provider. A slow confirmation can look like failure when money is still moving. Do not send the customer a second payable invoice simply because the first application's display has not refreshed.
Keep exceptions out of the first group. Disputed payments, multi-currency balances and services with unusual prorating need a separate review. The purpose of a pilot is to establish a repeatable handover, not to conceal complicated accounts inside a larger migration total.
Walk through a fictional monthly hosting handover
Suppose Example Hosting sells managed hosting for €29 per month. Customer A has paid for October and should next pay for November. The planning record says WHMCS owns October; PayRequest will own November only after the setup and payment checks are complete.
Confirm that the old system has not already requested November's payment. If it has, resolve that existing invoice or attempt before authorizing new billing. Do not change the first new date to today simply because the customer was imported today. Import date and paid-through date serve different purposes.
For Customer B, assume November is already paid in advance. The first new period should then follow that paid coverage, subject to the actual service terms. A blanket “all customers start on 1 November” rule would charge B for a period that was already covered.
For Customer C, assume October remains unpaid. Keep that debt identifiable as October. Establish November's billing owner separately, and decide how to communicate the overdue balance. Making the subscription active in a new portal does not establish that the older invoice was paid.
These are original examples, not reports of completed PayRequest migrations. Their value is the decision rule: each payable service period needs one documented owner, and previously paid coverage must remain visible in the new schedule.
Keep billing changes separate from hosting termination
Do not use service cancellation as a shortcut for disabling old billing without reviewing its effects. WHMCS cancellation documentation explains that service termination can involve a provisioning module and associated access. A billing migration should not accidentally become a hosting shutdown.
Record which system provisions accounts, handles domain renewals and processes overdue-service actions. If you keep WHMCS for these jobs, confirm how billing outcomes reach it. The presence of an API or webhook does not establish a working integration; someone must implement and check the actual lifecycle.
Limit each automation change to the approved group. Turning off a global job can affect customers who are still billed in WHMCS. Keep a record of changed settings and the intended scope, and have an operator verify what remains active for unmigrated accounts.
Use the cancellation handover guide when customers have pending cancellation requests. A customer who already asked to leave should not silently receive a fresh ongoing subscription during the migration.
Tell customers which invoice and portal to use
Send a short message that names the new billing portal, the first affected period and any action actually required. Avoid promising that all stored payment methods will transfer. Use the payment mandate readiness guide before deciding whether someone needs to authorize again.
A reusable message is: “From [first affected service period], billing for [service] moves to [new portal]. Your previous invoices remain at [document location]. Your next scheduled amount is [amount and currency] on [date]. [State the confirmed payment action]. If you receive two invoices for that period, contact [support route] before making another payment.”
Replace every bracketed field with the verified record. Do not send the template as a universal announcement when customers have different paid-through dates. Group communications by the actual handover period and explain separate domain renewals when those remain in the old system.
Review the public portal page as a customer. Check service name, currency, next date and invoice access. A correct internal spreadsheet is useful only if the customer sees matching information and knows which support route owns a question about the change.
Verify the first renewal and define when to roll back
The first renewal is the point where planning meets a real billing result. Check the invoice period, provider transaction, customer balance and hosting status together. If a provider attempt is pending, wait for a reliable result before deciding to collect again.
Define a stop condition before expanding the group: unexplained duplicate invoices, mismatched amounts, missing authorization or incorrect service access. Assign a person to resolve the exception. A smaller checked migration is easier to operate than a large batch whose errors are discovered by customers.
Rollback needs the same ownership discipline as launch. Check pending and completed new-system attempts before re-enabling old collection. Restoring the old job while a new attempt is still pending can recreate the duplicate you were trying to prevent.
PayRequest's subscription payment documentation distinguishes recurring invoices paid manually from automatic collection through a valid mandate. Review that distinction and the portal demo, then bring the completed worksheet to the migration assessment.
PayRequest Business costs €20/month and includes the customer portal and recurring billing. Standard platform payment fees are 0% while the paid plan is active. Provider processing fees apply separately; commission payments retain their separate fee. Complete account setup and activate Business at checkout. Selecting Business during signup does not itself grant paid access. Check current pricing before choosing your setup.
Editorial note: AI assisted with this article and its illustrative cover. Official documentation was reviewed on 7 October 2026. Worksheets and customer messages are original planning templates. All examples are fictional; no live charge, customer migration or hosting termination was performed for this article.
