BSG utilizes HTTP cookies (and similar or complementary technologies) to 1) make this website safe, functional, and accessible (through the use of mandatory cookies) and 2) understand how you use our website (through the use of optional cookies) in order to improve your experience and to provide you with personalized content.

The information in the cookie text files may be related to your personal preferences or your device and is intended to make the site operate according to your expectations. The information contained in cookies does not usually identify your identity directly but is helpful in providing you with a more personalized user experience.

In accordance with the requirements of the General Data Protection Regulation (GDPR) privacy and security law that governs how the personal data of individuals in the EU may be processed and transferred, we provide you the possibility to prohibit the use of certain types of cookies when you use our website.

Read our Cookie Notice and the Privacy Policy for detailed information on how BGS collects and uses cookies. Please note that prohibiting the use of certain types of cookies may affect your interaction with the website and limit the accessibility of services we offer you. Choose the appropriate category below to learn more and to disable cookies.

Accept All cookies*
*Recommended for comfortable use of the site
Accept only necessary cookies
Accept only selected cookies
Necessary cookies
Social media
Analytics
Marketing

Parallel Run

What is a parallel run?

A parallel run is a migration phase in which a controlled share of live messaging traffic goes through a new provider while the existing route carries the rest, so results can be compared before full cutover.

How does a parallel run work?

A parallel run turns a provider switch from a single risky moment into a measured process. Instead of moving all traffic at once, a business routes a small share of real messages — per country, operator and message type — through the new provider, keeps the rest on the current route, and compares the two.

The comparison usually covers four things: delivery statuses by operator against a baseline from delivery reports; how the sender name actually displays on handsets in each market; whether number lookups return the same network and status from old and new APIs; and how your own code handles the new webhook formats and error codes.

Why it matters: problems that never show up in a test console appear on live traffic — a sender replaced by a short code, a missing Sender ID registration, a response field your fraud rules read under a different name. Found during a parallel run, each is a configuration fix. Found after cutover, each is a customer complaint.

Example

A payments company moves a slice of its German transactional SMS first, checks delivery reports for a set period, then widens the share market by market.

Interested in a special offer?

Ready to reach further?
Let’s talk

I agree to BSG privacy policy
Submit

Useful Materials

Old messaging platform with SMS, OTP, lookup and WhatsApp streams moving to a new platform with WhatsApp and SMS fallback
Tyntec Alternative: Migrate SMS, Verification and WhatsApp Traffic

A five-step plan to move SMS, verification and WhatsApp traffic, with an export checklist and Sender ID rules by country.

Sender ID Registration in the EU and UK: Why Your SMS Gets Filtered
Sender ID Registration in the EU and UK: Why Your SMS Gets Filtered

Why unregistered senders get filtered in the EU and UK, and what each country requires for sender ID registration.

One Communication API for SMS, WhatsApp, Viber & RCS — Why It Beats Five
One Communication API for SMS, WhatsApp, Viber & RCS — Why It Beats Five

Why one communication API for SMS, WhatsApp, Viber & RCS beats five separate integrations — cascade fallback, unified reports.