Most pages discussing migration promise a seamless move where everything carries over without anyone noticing. This one tells you which parts are automatic, which parts are up to you, and which parts we will talk you out of.
Whether you’re transitioning from a softswitch with billing attached, a commercial BSS, or something your team built in-house, the steps and size of the job are determined by your data, product catalogue, routing, and every integration currently pointing at your billing system.
Three ways to migrate, and who does the work
The first decision resolves around who owns the project. To help you navigate this decision, consider the factors listed in the following table:
| Manual migration | PortaOne default import scripts | PortaOne-managed migration | |
| Who runs it | You | You, or PortaOne | PortaOne |
| How | Admin interface, or your own scripts on the PortaBilling API | PortaOne’s default import scripts, which ship with PortaSwitch | Custom scripts written by PortaOne for your specific project |
| Cost | Your engineering time | Free if you run them yourself; a paid service if PortaOne handles them for you | A paid project |
| PortaOne’s part | Support consults under your PortaCare agreement | Consults or runs the migration for you | Involves a project manager, business analyst, migration engineer, architect |
| Fits | You know exactly what you want moved, you have in-house API expertise, and you would rather spend time than budget | Standard entities, and data you can export to CSV | Large or unusual bases, product catalogues to remap, feature gaps to close |
Most migrations become managed projects rather than script runs. Default scripts often only carry a fixed set of entities, but most operators expect them to handle much more such as correct mapping of a product catalogue, transformation logic for data that does not line up, etc. You decide what gets migrated during the analysis phase. Once that scope is set, any changes can delay the migration date. Changing course later also comes at a cost: if you start the migration yourself and then hand it over to PortaOne, the work you’ve already done doesn’t carry over. PortaOne will need to start the pre-migration analysis again from scratch.
What the default import scripts carry
The default scripts cover five types of data out of the box:
- Customers
- Accounts
- SIM cards
- CPE profiles
- Account follow-me settings
That’s the complete list, and the boundaries it sets are fairly strict. An account with follow-me settings will import, but an account with call queue settings won’t, because call queues aren’t covered by the scripts. The scripts don’t apply any transformation logic either, so your source file has to arrive as a CSV in the structure expected by the scripts.
Anything beyond those five items takes one of two routes: you build the migration yourself against the PortaBilling API, or PortaOne writes custom scripts for your project. Roughly 90% of a custom migration script is transformation logic unique to each operator, which is why custom migration is project work rather than a product feature.
Why there is no upload screen for this
PortaSwitch has a large number of entity types, each with its own settings, and they need to be uploaded in the right order (e.g., customers before accounts). Rates and destinations get a wizard because you touch those every week while a migration is a one-time job, so a script makes more sense.
What we usually leave behind
This is where most of the effort hides, and where most of it can be avoided.
A typical migration moves active customers and accounts, with their current balances but it does not normally move:
- closed or inactive customers and accounts
- charge history
- invoice history
- logs
- legacy products nobody sells any more
Charge history is the one people ask about most. We normally suggest keeping the old system accessible for a certain period to look up history. This means less work on both sides, and the history remains accessible in the system it originated. If you need that history inside the live system, raise it during analysis, because adding it after the scope is agreed affects both the timeline and the price.
How a PortaOne-managed migration runs
Every PortaOne-managed migration starts with pre-migration analysis, and the process is the same regardless of the source system:
- Document your business processes. This includes onboarding, provisioning, invoicing, suspension, collection, etc. Most operators have some of this written down, though it’s usually out of date. The harder cases are those legacy processes that were never documented and that nobody is sure you still need.
- Look at the real data. Sample exports, entity counts, database size, and whether the base can move in batches.
- Map the integrations. Identify every system that connects to and communicates with your billing platform today including your CRM, provisioning, self-care, accounting, payment gateways, and the protocols between them.
- Refine the data. Leave behind what you no longer need. Decommission products you no longer sell, and decide whether others could stay on the old platform and be phased out rather than remapped.
- Map your processes into PortaBilling and find the gaps. If you rely on something your current platform does that PortaSwitch doesn’t yet support, this is the time to identify it.
- Build a proof of concept and end-to-end acceptance tests, so “it works” means something specific.
Out of that comes a scope of work that identifies what will be migrated, sample source files, a migration decomposition, a responsibility matrix, and a target system design describing how your processes will run on PortaSwitch afterwards.
Then the migration runs in batches, validated against the old system, with both platforms live until the new one handles most of the workload.
When PortaSwitch does not do something you need today
Most replacement migrations uncover at least one gap. When that happens, you have four options:
- PortaOne builds the feature, and the affected customers migrate once it ships
- You or a third party build it alongside PortaSwitch
- You simplify the product line and move those customers onto a product that does migrate
- That segment stays on the old platform
The first option adds a project. Closing a feature gap involves business analysis, solution design, implementation, delivery, and user acceptance testing. Once the feature is ready, the mapping and source files need to be updated, scripts readjusted, and testing repeated. That can add months to the schedule and is the most common reasons migrations run past their initial estimates.
How long it takes, and what makes it slip
Three months is the realistic minimum for a small, clean migration. It grows with the number of products, segments, integration points and end-to-end service flows you run.
What actually causes delays:
- One person who knows the legacy system. If that knowledge sits with a single engineer who is also doing their day job, they become the bottleneck. Assigning a subject matter expert with dedicated time is the most valuable asset you can introduce.
- Source data nobody can explain. We need sample exports and someone who can say what a field means. Getting that information from your current vendor can be difficult, so find out early what information they can provide.
- A feature gap on the critical path. See the options in the previous section.
- Change requests. Scope creep where each addition moves the date.
- Hardware lead times, unless you are going to the cloud, plus security requirements such as VPN access into your environment.
- Reports. Built-in reports will not cover everything you have today. Anything beyond them means PortaOne AI Datalink or direct database access, and someone on your side learning the schema.
- A staging system. Most operators don’t realize they need a dedicated test bed until after they migrate. The larger the installation, the more important it becomes.
- Your integrations. A migration can only move as fast as the CRM, provisioning, and portal work it depends on, and that work is usually outside of PortaOne’s scope.
Just as important is what’s not on this list. Firewall rules and IP whitelisting come up in every migration but can usually be sorted in an afternoon.
Migrations PortaOne has run, just to name a few
TeleBermuda, from Advantage360 to PortaSwitch, and the first migration PortaOne ran end to end. This included on-site business analysis, custom migration scripts, 200+ subscriptions, 100+ tariffs and 300+ products built, roughly 15,000 active customers with accounts and cards migrated plus 28,000 inactive, and a custom invoice template built by PortaOne to cover TeleBermuda’s specific requirements.
Telekom Malaysia, roughly 500,000 prepaid calling-card customers off the obsolete iTALK platform. PortaOne engineers mapped products and tariffs, wrote and tested the migration scripts, and cut over in off-peak windows. Source: Telekom Malaysia case study
Cgates, a Lithuanian triple-play provider with 137,325 customers moved off an unsupported in-house billing system, 12 backend systems, both platforms running in parallel with new customers going to PortaBilling first. Sources: Cgates case study and the Cgates migration podcast (video, 32 min)
What PortaOne does not do
- No upload screen for customers, accounts, or resellers. Scripts and the API do this work.
- Routing does not come across. No two platforms share a routing rule format. Routing plans, carrier connections, and routing rules get rebuilt, and the connections get verified from PortaSwitch afterwards.
- Reporting is not what PortaSwitch itself was designed for. It is not a CRM nor a reporting platform. What it gives you is PortaOne AI Datalink and direct database access, so anyone can build any report they want with SQL. If you rely on specific reports today, list them during analysis.
- PortaOne does not extract your data for you unless that is explicitly in scope. Getting a clean export out of the old platform is normally your responsibility, and the part most often underestimated.
Start with the checklist
These are the answers that decide whether a migration is a three-month job or a three-year one. If you already have documentation covering this, you can simply share it.
Your business
- Which services do you provide?
- How many semi-independent business units or brands do you have, each with its own products?
- For each entity, how many active products, and roughly how many subscribers on each?
- A short description of each product noting services included, rating rules, and add-ons
- How many legacy products are still in use but no longer sold? Could any stay on the old platform and be phased out?
- Will someone who knows the current product setup in depth be available during analysis and migration?
Your technical setup
- A diagram of the network elements connected to your charging and billing, and the protocols between them. Is there anything proprietary?
- Who are the vendors of those elements, and is vendor support available for troubleshooting?
- Which other systems connect to billing (e.g., accounting, self-care, a CRM)? What do they exchange and over which APIs?
- Can your current platform export subscriber data to CSV?
- Is there someone who can explain what specific fields mean, and adjust the export if needed?
- Which reports do you rely on today that would have to exist on day one?
FAQ
PortaOne’s default import scripts migrate five types of data out of the box: customers, accounts, SIM cards, CPE profiles, and account follow-me settings, read from CSV. Anything beyond that list is created through the PortaBilling API, either by your team or by custom scripts PortaOne writes for the project. A typical migration moves active customers and accounts with their current balances, and leaves closed accounts, history of charges, invoice history and logs in the old system.
PortaOne normally recommends leaving CDR and invoice history in the old platform and keeping it readable for a period, rather than loading it into PortaBilling. A migration moves the customer’s current balance, not their charge history. If history has to sit inside the live system, raise it during pre-migration analysis, because PortaOne scopes that separately and adding it after scope is agreed changes both the timeline and price.
No. No two platforms share a routing rule format, so routing plans, carrier connections and routing rules are rebuilt in PortaSwitch rather than imported. PortaOne then verifies each carrier connection from PortaSwitch before traffic moves. Plan for rebuild time, not import time.
Three months is the realistic minimum for a small, clean migration to PortaSwitch, and it grows with the number of products, segments, integrations and service flows involved. PortaOne estimates the timeline during pre-migration analysis, after seeing sample data exports. The most common reason a migration runs past its first estimate is due to a feature your current platform has that PortaSwitch does not support. Closing that gap becomes a separate development project.
You do, unless extraction is explicitly in the scope of work. PortaOne needs sample exports and someone who can explain what each field means. Getting a clean export out of the old platform is one of the most commonly underestimated parts of migration, and the difficulty often lies with your current vendor rather than your own team.
Yes. PortaOne migrates customers in batches, with the old platform and PortaSwitch both live, and validates each batch against the old system before the next one moves. Cgates ran both platforms in parallel across 137,325 customers, with new customers going to PortaBilling first.
It depends on which of the three routes you take. Running PortaOne’s default import scripts yourself costs you engineering time, since the scripts ship with PortaSwitch. Having PortaOne run those scripts is a paid service. A PortaOne-managed migration is a paid project with a project manager, business analyst, migration engineer and architect, scoped after pre-migration analysis.
PortaOne provides four upfront options: build the feature so the affected customers migrate once it ships, you or a third party build it alongside PortaSwitch, simplify the product line onto a product that does migrate, or leave that segment on the old platform. Building it adds business analysis, solution design, implementation, delivery. and acceptance testing, then a remap of the source files, so expect the process to take months rather than weeks.
