top of page

Best Practices when Migrating to Synthetic Monitoring as a Platform

Several monitoring products will no longer be available in 2024, so it's time to migrate your current monitoring scripts to a new solution. If you are still using TMART or Silk Performance Manager, you might have just a few months to evaluate and migrate to a new product.

What is Synthetic Monitoring?

We use synthetic monitoring to identify outages in critical services before end users are impacted. It is often called active or proactive monitoring because we measure the performance and availability of business applications, websites, or IT services.

Looking at the entire monitoring stack, synthetic monitoring is critical to detect outages, measure service level agreements, validate performance perspective, and provide a 24/7 track record about the health of your mission-critical services.

Technically, we use scripts to simulate API or user requests and execute them on a schedule to check the availability or performance of our most essential services. If preconfigured thresholds or content checks fail, we escalate these problems to operational teams for remediation.

Evaluate Synthetic Monitoring solutions

Finding a powerful and flexible synthetic monitoring product can be time-consuming. You might collect a long list of products and read through all their feature descriptions. A faster and more reliable option is to involve subject matter experts because this avoids re-inventing the wheel and saves a lot of time.

We follow this approach when we evaluate Synthetic Monitoring solutions

  1. Describe your requirements

  2. Describe features of the current solution

  3. Create a product comparison matrix

  4. Create a shortlist

  5. Evaluate the top 3

  6. Finalize your decision

Migrate to a new Synthetic Monitoring Platform

As with any migration, you must plan all activities upfront to avoid surprises down the line. As a first step, you could plan your infrastructure requirements, such as development, testing, and production environments. Keep future growth estimations in mind and ensure that your platform is scalable. Once the infrastructure is in place, you could design the script development and maintenance approach. In some cases, monitoring as code could make sense because it allows a more reliable way of managing critical monitoring features.

In one of our recent projects, we've supported a migration from Silk Performance Manager (TMART) to STEP. In this project, our customer fundamentally changed his monitoring practices from a Competence Center to a Platform approach.

Synthetic Monitoring as a Services

We tried to get everything "as a service" in the last two decades. Translated to monitoring, a central team deploys the platform, implements the scripts, oversees the monitoring configuration, and supports troubleshooting. You can bundle the expertise, but this comes with a high price in terms of scalability. If demand increases or declines, you might end up in lengthy delays or team members sitting idle.

Synthetic Monitoring as a Platform

The scale at which we operate synthetic monitoring in enterprises is too high to manage all monitoring scripts and configurations from a Competence Center. Handling over or under-capacity can put your business at risk, so we suggest the "Synthetic monitoring as a platform" approach.

Instead of writing all the monitoring scripts by a centralized team, in the platform approach, you shift the responsibility to the left and make monitoring a crucial activity of product and service teams. Of course, you can keep a small group of synthetic monitoring experts operating the platform and train developers and product teams on sharing best practices. But, the burden of implementing and maintaining synthetic monitoring no longer remains for the monitoring team.

Happy performance engineering! Keep up the great work!

25 views0 comments

Recent Posts

See All


bottom of page