BroadWorks Enterprises & Service Providers
On the Wrong Servers?

BroadWorks Enterprise and Service Provider can only be built on a single Application Server (AS) Cluster. Both could include thousands of invidual settings and features, such as groups, call centers, devices, and users (and all their greetings, passwords, and settings). When you create a Service Provider or Enterprise on an AS cluster, BroadWorks provides no method to move to another cluster. The more Enterprises and Service Providers you put on a server, the greater your risk due to migration and downtime.

So, what happens when you really need to move users to a new server?

Scenario 1 Cap and Grow for Safety?

“The server maxes out every day at peak hour creating an outage.”

One common method to attempt to prevent over-growth is to cap-and-grow physical servers, limiting their server utilization, hoping that customers never outgrow the servers they’re on. In this method, a server is “capped” to prevent new enterprises from being added, and growth occurs on separate servers. This requires sophisticated guesswork, and sometimes customers expand beyond their growth expectations. BroadWorks operators cannot always know which customers will grow.

With Alpaca, our BroadWords management toolset, there’s no need to overplan for growth ahead of time. As server limits are reached, enterprises and service providers can be migrated easily, with minimal downtime.


Scenario 2 Critical Organizations in Hosted Environments

“My key customers don’t want to upgrade when I upgrade everyone else.”

Sometimes a medical facility, police department, or government needs to influence the schedule of upgrades, patching, and tests. In these cases, a private BroadWorks cluster can be the best option.

With Alpaca, the special enterprise can be readily moved to a private installation. Once the critical organization is migrated to a private BroadWorks Cluster AS, the BroadWorks operator can provide all the same features in a hosted environment, but with the isolation required for consistency, stability, and scheduling.


Scenario 3 Merge and Normalize

“I’m frustrated that we merged with another company, but can’t merge our BroadWorks applications.”

A small, legacy AS cluster system (such as one brought in through an acquisition) may have some enterprises and service providers that need to be merged into a new, modern platform. This leaves you with the cost of a difficult manual migration, or inconsistent features and service offered to all your customers.

Alpaca makes it easy to move those enterprises/service providers to a new platform. The enterprise, user, and group IDs can even be transformed in the process. This ensures that all identifiers are built consistently under the standards of a new server.


Meet Alpaca

We built the Alpaca toolset to solve all these problems and more. Move enterprises and service providers to new servers, put users in the proper groups, move groups into the right service, and build robust custom tools without hacking XML. Alpaca can even export all your settings to JSON files for easy backup and inspection.

Find out more about Alpaca