Note: This blog is based on a presentation that includes slides. Click here to listen to the recording.
If you’re running earlier versions of Application Performance Management (APM), including version 10.7, on-premises and considering upgrading to DX APM SaaS, you’re undoubtedly curious what the migration process might look like. In this blog post, I’m going to share the story of one of Broadcom’s Fortune 50 customers and how they successfully migrated more than 30,000 production agents while navigating time constraints around their busy holiday season. We’ll take a look at the process, key considerations before you migrate, and a few lessons learned.
Reasons to Migrate
Your reasons for migrating to SaaS may differ, but for this customer, their on-premises APM was at capacity, and as they looked toward anticipated growth, they couldn’t justify the investment in hardware and labor that would be required if they stayed on-premises. They also wanted the advantage of getting the latest feature updates immediately, as Broadcom Software’s next-generation feature updates are released to SaaS first. And finally, they wanted more visibility into their infrastructure and applications than their on-premises APM version could deliver.
Consequently, they choose to migrate to DX APM SaaS.
Results
Before we get into the process, let me tell you the results. This customer successfully migrated more than 30,000 production agents, with 6,000 more agents to follow in an incremental migration. They acquired powerful new dashboards that offered improved visibility into hosts, clusters, containers, and applications. They were also able to take advantage of Broadcom’s EasySeries toolset, which automates the migration and onboarding process. Because their business peaks during the holidays, they needed to be able to avoid dealing with the migration during that time, which they were able to do.
Preparing for the Migration
Before a migration of this caliber can take place, there are a number of issues that need to be addressed. We have a robust project plan that we use when working with customers. These plans include these elements:
- Security. This is a primary factor, even though it can be easy to trivialize security in a migration like this because the monitoring data itself isn’t sensitive. However, part of ensuring security requires addressing operational risk. That means every place security is employed—such as cloud security gateways, proxies, and network security—must all be evaluated. Migrating to DX APM SaaS isn’t like moving to Salesforce. DX APM SaaS constantly transmits data, so factors like network capacity and bandwidth costs come into play. How will existing security mechanisms handle this traffic? We do a thorough security review in the planning stage.
- Training. End user training also needs to be addressed in the planning phase. There will be new features and capabilities in the SaaS version, so end users need to be trained on this new functionality and how to take advantage of it. This customer required training, so end users were informed about the new version before they were affected by the migration.
- Project management. Managing projects with technical insight is another key consideration. There are many good project managers, but for a migration like this you really need someone with enough technical background to know if things are actually progressing as they should. Many project management efforts end up being technical in nature and having a technical background will help ensure tasks are actually getting completed correctly.
Using the Cloud Proxy for Incremental Migration
As mentioned above, this customer needed to avoid migration work during their peak holiday season. One way you can manage a migration, without having to reconfigure or upgrade your agents all at once, is by using a cloud proxy. The cloud proxy is an on-premises software gateway that sends agent traffic to a SaaS tenant. In this customer’s environment, we used different cloud proxies to get agents to different tenants. Instead of reconfiguring agents to point to the installed cloud proxies, we employed an existing manager of managers (MoM) and its loadbalancer.xml file to direct agents to the cloud proxy. This allowed the customer to centrally manage agent traffic, without touching the agent's configuration. The customer will eventually need to upgrade some legacy agents, but they can do this incrementally on their own schedule.
EasySeries Tools Automate the Process
Needless to say, there’s a lot of configuration effort that needs to happen when migrating to SaaS, particularly to enable all the new features. We have a set of tools, called EasySeries, that automates the migration and onboarding experience. In addition, there are templates with best practices that help eliminate guesswork from migrations. This helps speed time to value. This customer used EasySeries tools, which made it much easier to build out the infrastructure that would ultimately be used.
Moving from Traditional Alerts to DX Operational Intelligence
One of the biggest differences customers see when they migrate to DX APM SaaS is how alerts work. In the SaaS solution, alerts are sent to the DX Operational Intelligence platform. This platform provides the infrastructure to apply alerts to cross-product service topology views and use artificial intelligence for cross-product root cause analysis. The DX Operational Intelligence platform leverages attributes to control the stream of alerts and to manage notifications. Notifications in the platform are expanded from the simple email, scripts, and console notifications found in the on-premises solution. The platform has support for HTML email, Slack, generic webhooks, and out-of-the-box ticketing integrations with ServiceNow, Remedy, and more.
Most customers find DX Operational Intelligence to be invaluable. However, if for any reason customers want to continue to use their legacy notification systems, they can use webhooks to send alerts from the SaaS system to their on-premises system.
Gain Broader Visibility into System Health
For this customer, it was important to gain broader, deeper insight into their infrastructure. DX APM SaaS provides them with more sophisticated monitoring than APM 10.7. DX APM SaaS uses a Universal Monitoring Agent (UMA) that enables customers to monitor host, cluster, container, and application health, and it tracks layers of topology to understand the relationships between these components.
In Design Partnership with Customers
As with all enterprise software deployments, surprises come up. At Broadcom Software, we partner with customers to establish designs that support their specific needs. In addition, if enhancements are required, we work collaboratively to develop a solution. Our recent engagement with this particular customer offers an example of this type of collaboration. This customer was running Azure Active Directory (Azure AD) for all users. However, at that point, we didn’t have the solution on the Azure Marketplace. Through this project, we worked with our engineers to put DX APM SaaS on the Azure Marketplace, which made it easier for this customer, and future customers, to access the solution.
The Results
This particular customer has made a significant corporate investment in OpenShift and has been building and migrating applications to the platform for a few years. With that effort accelerating, it was important for them to deploy monitoring quickly.
With UMA automatically discovering and instrumenting applications, this customer was able to deploy monitoring in a short time across more than 1,000 nodes, without requiring any changes to application deployments. With the solution’s built-in multi-tenancy support, the customer was able to rapidly scale monitoring across the enterprise.
Since the holidays, the customer has continued their push to migrate more than 150 applications to OpenShift, and their teams started migrating the remaining 6,000 agents into SaaS. The next project has already begun: They plan to upgrade legacy agents and manage them using the APM Command Center (ACC).
This is a high-level overview of what a migration looks like. If you’d like to learn more, you can view the resources below:
- Blog Post: Migrating to DX APM FAQs
- Blog Post: 11 Reasons Why You Should Migrate to Next-Generation DX APM
- White Paper: Migrating to Next-Generation DX APM
In addition, feel free to reach out to us in the APM Community and we’d be happy to talk with you about your own migration process.