An ISP billing launch should have a clear first milestone: a small, agreed group of subscribers can complete the intended journey, and the support team can explain how that result was verified. Expanding before that milestone makes it harder to distinguish a configuration problem from an account issue, a payment problem or an incomplete handover.
A staged launch is an operating method, not a promise that every migration can finish within a fixed number of minutes. The plan should reflect the existing network, the records being moved and the services that must remain available. The following checklist helps a team organize that work without assuming undocumented product features or applying a universal router configuration.
Describe the launch scope in plain terms
List the services included in the first stage. Identify the router or site, the subscriber group and the billing functions that will be tested. State which existing services must remain unchanged during that stage.
Name the person responsible for the launch decision and the people responsible for network, billing and customer support tasks. Agree how they will record progress and communicate a blocker. An unresolved question should have an owner rather than being passed between teams without a next step.
Define acceptance in terms of observable results. For example, a test subscriber should be associated with the intended package, complete the supported authentication process and reach an agreed external destination. If the launch includes payments, include a separate test of the configured collection workflow. Keep the test scope explicit so that a successful network check is not mistaken for verification of an untested payment integration.
Inventory the existing service before making changes
Record the equipment, software versions and service paths involved. Identify management access, upstream connectivity, subscriber interfaces and any dependencies that the launch could affect. Use the approved network design and the configuration actually present on the devices.
On the billing side, identify the records and rules being introduced or moved. Review subscriber identifiers, packages, service periods and any exception that needs a deliberate decision. Resolve ambiguous account matches before including those accounts in the pilot.
Keep the inventory useful to the people doing the work. It should explain which information is confirmed, which is still being checked and where the authoritative record is held. Do not place credentials or reusable enrollment tokens in a shared checklist. Refer to the approved credential store or access procedure instead.
Prepare recovery before the pilot
Confirm that the responsible engineer has the recovery material required for the proposed network changes. Store it securely and check that it can be located when needed. A backup filename in a chat is not a complete recovery plan if nobody knows which device or configuration it belongs to.
Document the condition that would stop the launch or trigger rollback. Identify the decision maker and the practical access needed to restore the affected service. Arrange on-site assistance where a loss of remote management would otherwise leave the team without a recovery path.
Apply the same discipline to billing records. Preserve the information needed to explain the previous account state and the intended transition. Avoid irreversible cleanup while the pilot is still being evaluated. Any later removal of obsolete records should follow a separate, reviewed process rather than being hidden inside the launch test.
Enroll and configure a deliberately limited scope
Use the current instructions presented by the platform for the selected router and workspace. Read the CENTRANET MikroTik provisioning guide alongside the actual setup flow, and resolve differences with support before applying an uncertain change.
Review the service assignments and the management path carefully. Confirm what the proposed configuration affects and what the operator intends to retain. Do not copy an enrollment command from an unrelated router or assume that an old command remains valid for a new registration.
Observe the reported progress and record any failure at the stage where it occurs. Repeatedly starting the same setup without understanding the existing state can make the evidence harder to interpret. When a step fails, capture the relevant status and follow the documented recovery or support path for that step.
Test the subscriber journey from the access side
Use a designated test device and account. For a HotSpot deployment, verify access to the intended portal and then the supported login journey. For PPPoE, verify the appropriate connection sequence and the resulting session. Refer to MikroTik's HotSpot documentation or the corresponding PPPoE documentation for the deployed service.
After authentication, test name resolution and traffic to agreed external destinations as appropriate to the service. Record the device, connection path, timestamp and outcome. A router that is reachable for management is useful evidence about management access, but the subscriber's path needs its own acceptance test.
Where the pilot includes renewal, expiry or suspension behavior, define those tests in advance and perform them on authorized test accounts. Record what actually happened rather than assuming that a displayed account status proves the intended network effect.
Verify the configured payment workflow separately
Confirm which payment product and integration are actually available for the workspace. Obtain the current setup and testing instructions from the responsible provider or platform support. Do not assume that sandbox credentials, a simulator or particular webhook controls are included merely because a blog describes them.
Agree on a test procedure before initiating a transaction. Use provider-supported test facilities where available, or an explicitly approved controlled live test when that is the appropriate process. Match the resulting transaction to the intended test subscriber and package through the supported billing workflow.
Keep the evidence for collection, account state and subscriber access distinct. If one step fails, investigate that step without asking a real customer to pay repeatedly. Record any permitted correction and its outcome. Avoid inventing a fixed test amount or a guaranteed processing time; the correct procedure depends on the configured collection product and the operator's approvals.
Run a pilot that the support team can observe
Choose a pilot group whose scope the team can support and monitor. Explain how participants can report a problem and what information will help the investigation. Make sure the people answering those reports can see the agreed test and change records.
Review each exception before expanding. Classify whether it concerns account data, the payment workflow, authentication, the access network or the customer-facing instructions. Assign a responsible person and a next action. A small set of well-described exceptions is more useful than a large collection of screenshots without context.
Use the pilot findings to update the launch checklist. If customer instructions caused confusion, correct those instructions and repeat the relevant test. If a network change affected an existing service, resolve and document that dependency before including another site or subscriber group.
Make a clear decision before expanding
Compare the pilot results with the acceptance criteria agreed at the start. List the checks completed, unresolved limitations and any conditions required for the next stage. The decision should be based on that record rather than on the absence of complaints during a short observation period.
Expand in a scope the team can still verify. Retain a way to identify which subscribers belong to each stage so that support can relate a report to the relevant changes. Carry forward the same recovery, communication and evidence requirements instead of treating later stages as routine copies that need no review.
Do not turn a successful pilot into an unsupported capacity claim. Hardware suitability, traffic patterns and the configured services still need assessment as the deployment grows. Plan further measurements and engineering review when the operating conditions change.
Hand over the service and the remaining work
Finish each stage with a concise handover. Include the approved scope, configuration and account changes, subscriber-side test results, payment tests performed and any remaining action. Name the next owner and state where the detailed records can be found.
Confirm the customer-facing support route and the process for reporting a recurrence. Keep temporary test accounts and diagnostic access under control, and remove them through the approved process when they are no longer needed.
Contact CENTRANET to plan a staged rollout around your existing network and billing workflow. A clear inventory and agreed acceptance tests make that planning conversation more useful than an arbitrary deadline for going live.