Have you been thinking of replacing your current APM solution with AppDynamics but don’t know where to start? This can be a very difficult decision given the time and effort invested by your company and you personally in getting your current APM solution up and running. Chances are, it took months or even years to get the hardware ready, change management approvals obtained, and all the agents rolled out. And then, it took some additional months to get the system configured and integrated with LDAP, your ticketing system, and your network monitoring system. Of course, it took even more time to design and build those custom dashboards that are proudly displayed in your CIO’s office and at the entrance to your main datacenter. But after all of that effort, you find that your APM solution does not scale all that well and doesn’t automatically adapt to environment changes as you expected it would. Often, people in the organization feel that when you replace a solution, this is indicative of a mistake in choosing the previous solution. While this may be the perception, it is important to remember that organizational or technological changes, from the vendor or within your own organization, dictate that a change is necessary. You need to look for the best tool to fit your needs.
AppDynamics is that tool. It scales and adapts to changes and installs in minutes. Yet the thought of starting again from scratch makes you very nervous. Where do you start? How do you do this in such a way that your previous investment is properly leveraged, and not simply discarded along with the legacy solution? How do you minimize your efforts and improve the outcome?
Being the APM leaders, we help our small, medium, and enterprise customers work through these issues every day, helping them transition from legacy APM solutions to AppDynamics.
In this blog we describe a simple and pragmatic 7-step approach to replacing a legacy APM solution.
STEP 1. Plan your replacement strategy by conducting a Solution Architecture Workshop with AppDynamics Solutions Architect.
AppDynamics Solutions Architect will conduct a series of meetings with your APM project stakeholders to:
- Understand the architecture, usage, integration, and other specifics of the legacy APM solution to leverage previous investment to a maximum extent
- Design overall APM Architecture for the AppDynamics solution leveraging experience gained from previous implementation
- Design a rollout plan, including:
- Identifying a set of applications in a Test Environment for which you will replace your legacy solution with AppDynamics
- Planning AppDynamics solution testing and comparative analysis for these applications
- Identifying applications in the Production Environment for which you will replace your legacy APM solution with AppDynamics
- Repeating steps A-C for the rest of the applications monitored by your legacy APM solution
- Design a plan for integration with other monitoring third party systems the legacy APM solution integrated with originally
- Design a plan for rebuilding custom dashboards that leverages the capabilities of AppDynamics
The first step in this process is very important as it allows us to leverage and re-use the design decisions that were made previously when designing the legacy APM solution. Clearly not everything will be reused, but applicable solutions and processes can always be incorporated in the new Solution Architecture to build upon the previous investment. The insights you have gained previously will be leveraged to build a better solution than would be possible without the investment you have already made.
Following these meetings, the Architect will create an AppDynamics Solution Architecture document capturing the solution design as well as a blueprint for the solution replacement implementation. This document will be reviewed with the APM project stakeholders and updated and tuned as necessary. It will be a working document that will continue to be updated throughout the implementation process if new details come to light.
STEP 2. Replace the legacy APM solution with AppDynamics for the first set of applications in a Test Environment.
The applications you choose for the first round of instrumentation with AppDynamics should include applications that are representative of the types of performance issues you are looking to troubleshoot with AppDynamics. It is best to include applications that communicate with each other, from the front end, through services, to the back end, so you get the most value from AppDynamics immediately. It’s best to limit this set of applications to 2-3, to make quick progress and start evaluation testing and comparative analysis as early as possible.
STEP 3. Perform AppDynamics solution testing and comparative analysis for these applications
This step typically includes a monitoring feature comparison as well as testing agent overhead under load. Part of this process is also identifying how the use cases for AppDynamics may differ slightly from the use cases for your legacy APM solution. It is during this part of the process that you will develop the first health rules, alerts, and dashboards for consumers of APM within your organization. The focus at this time should be on a few representative dashboards, alerts, etc, not on a wholesale replacement of everything configured in your legacy APM solution.
STEP 4. Replace the legacy APM solution with AppDynamics for the first set of applications in the Production Environment
Once solution testing is completed, we can deploy AppDynamics for the same set of applications in Production. As part of this step, the first health rules, alerts, and dashboards will be enabled in production and you will begin socializing this new toolset with users in your organization. After you are comfortable with how AppDynamics is performing and is being used, the alerts for the first applications should be configured to be delivered to the relevant alerting systems.
STEP 5. Repeat steps 2-4 for the rest of the applications
Now you can move a lot quicker, you’ll only need the feature comparison and test the agents that haven’t been tested before, such as agents running on a different platform. As you are rolling out to the other applications, your AppDynamics Solution Architect will engage with you to refine the solution architecture design as necessary.
STEP 6. Integrate AppDynamics with other monitoring third party systems the legacy APM solution integrated with originally
Here we can heavily leverage designs and possibly even partially leverage integration implementations for the legacy APM solution. During this step in the process, the focus is on assessing which features from your legacy APM solution we want to port and which are less meaningful due to the advanced feature sets of more modern APM solutions. Here, we would also design custom dashboards following the designs of the previously available custom dashboards, if so desired. Additionally, there should be a focus on bringing in useful metrics from other monitoring systems to overlay on top of what AppDynamics provides.
STEP 7. Train and enable the Enterprise on AppDynamics
Some users will quickly understand how to use AppDynamics during the core implementation steps, but there is a larger audience of users who will need to be brought up to speed. No solution will ever work if users don’t know how to use it. AppDynamics offers a lot of self-study materials as well as instructor-based classes to help our customers transition from legacy APM solutions quickly and easily.
That’s it! If you need any help with planning and implementing this transition, please visit the Education and Enablement page on AppDynamics.com. For AppDynamics Center of Excellence Best Practices Guides, please visit community.appdynamics.com.