Datadog Alternative: What Would You Have to Rebuild?

Every plan we have read for moving to a Datadog alternative starts in the same place: swap the agent, re-point the SDK, done inside a sprint. That part is real work, and it is also the part that goes roughly to plan.

The overrun is everything that is not telemetry. Four hundred monitors written by people who have since left. The dashboard the payments team opens during a settlement window. The tag names half your alert queries are built on. None of it moves with the agent, and no tool exports it into another.

So here is the position. The instrumentation is the cheap half and the operating layer is the bill. Make that layer portable while you are still happy where you are, and the switch becomes a decision rather than a project.

Why does every migration plan stop at the agent?

Because the agent is the only part with a documented procedure. Datadog publishes it itself. Its Collector setup guide calls an OTLP HTTP exporter pointed at https://otlp.<YOUR_DD_SITE> "the recommended setup for a Collector you manage yourself", which means you can run vendor-neutral instrumentation today and keep sending it to the tool you already pay for.

It is under-used. Most teams read it as a migration step and put it off until they are migrating, when it is better read as insurance: the day you need it is the day you have least time.

What has no documented procedure is the rest: the monitor that fires on a percentile of a tag someone set three years ago, and the notebook nobody has opened since the incident it was written for.

What do you give up by instrumenting with OpenTelemetry?

Something real, and Datadog is unusually straight about what. Its feature compatibility table shows that on an OpenTelemetry SDK, even paired with Datadog's own Collector distribution, App and API Protection, the Continuous Profiler, Data Jobs Monitoring, Real User Monitoring and source code integration are not supported. Data Streams Monitoring is marked not applicable, because OpenTelemetry has no equivalent. The overview page puts the general case plainly: "using the OpenTelemetry API with the Datadog SDK provides access to more Datadog features than using the OpenTelemetry SDK alone."

Read that list against your invoice, not against the marketing. For most of the fintech teams we work with it is survivable. Real User Monitoring is a product decision browser teams make on its own merits, and the profiler tends to be the thing two engineers love and nobody else opens.

If you are running App and API Protection in blocking mode, or the profiler is how you catch regressions before release, then OpenTelemetry costs you a capability and you should price that honestly. Portability is not free. It is just usually cheaper than the alternative, which is finding out what it would have cost in the middle of a renewal, with nothing left to trade.

What happens to your tag names when the telemetry changes shape?

They get translated, and the translation is what bites. Datadog's semantic mapping converts OpenTelemetry resource attributes into its own tag names on the way in: service.name becomes service, deployment.environment.name becomes env, k8s.namespace.name becomes kube_namespace, container.id becomes container_id, http.response.status_code becomes http.status_code.

Two consequences, and neither is obvious until you are in it. The first is that every monitor and dashboard query you have ever written is written against the Datadog-side name. Move to a backend that speaks OpenTelemetry natively and those queries all refer to attributes that are now called something else. It is a find and replace, across hundreds of saved objects, done by someone who has to know which ones still matter.

The second is quieter. The same page notes that by default Datadog maps only the resource attributes in that published table to metric tags. Anything you set outside it, your own tenant.id or merchant.tier, needs configuring explicitly. Teams discover this when a dashboard that worked on the old agent comes back empty, usually at the end of a long week.

The practical move: write new queries against the OpenTelemetry name wherever the backend accepts it, and stop inventing tag names only one vendor will understand.

Can you keep the monitors if you keep them in code?

Not literally. A monitor query is written in the vendor's query language and nothing imports it. What changes is the nature of the job.

Monitors in a repository make the move a translation exercise: a known list of files, reviewable, diffable, assignable to someone who was not there when they were written. Monitors defined by clicking make it archaeology. Somebody opens each one, works out whether it has fired in the last year, and decides whether it deserves to exist in the new tool. That step quietly eats a month, because it needs judgement from the people also carrying the pager.

Keep the same habit for the archive. If your compliance copy of logs already lands in a bucket in your own account, the tool in front of it is swappable and the regulator's requirement is untouched by any of this. CERT-In's directions of 28 April 2022 ask for a rolling 180 days of logs maintained within Indian jurisdiction, and a bucket in ap-south-1 with object lock meets that whoever is drawing the graphs. Hold those 180 days inside the vendor and the retention question re-opens every time the vendor does.

The honest concession: for an estate of twenty monitors, putting them in Terraform is slower than clicking them and you will not get the time back. Under roughly fifty, click them and keep a note.

How do you make a Datadog alternative a decision rather than a project?

Three things have to be portable, and you can do all three without leaving.

Instrumentation, by moving to OpenTelemetry SDKs service by service as each one gets opened for some other reason. Not a migration sprint. A rule: new services use OpenTelemetry, old ones convert when next touched.

Definitions, by holding monitors and dashboards as code beside the service they watch, so whoever owns the service owns the alerting on it.

Retention, by keeping the compliance archive in your own bucket and letting the tool hold only the fortnight engineers actually search. That is also the largest line on most bills, which is why it turns up first in what a fintech on AWS can actually cut.

Do those three and the residency question, the one that usually forces the decision for a regulated company, becomes answerable in weeks rather than quarters. We went through which tools can even be run in India in the post on where the data actually lands, and the billing units that decide the cost in hosts or active series.

What can you count on Monday?

Twenty minutes, and you have the number the quote is missing. Use your own site host: api.datadoghq.com for US1, api.ap1.datadoghq.com for the Tokyo site.

DD_HOST=api.datadoghq.com

curl -s -H "DD-API-KEY: $DD_API_KEY" \
     -H "DD-APPLICATION-KEY: $DD_APP_KEY" \
     "https://$DD_HOST/api/v1/monitor" \
| jq 'group_by(.type) | map({type: .[0].type, count: length})'

curl -s -H "DD-API-KEY: $DD_API_KEY" \
     -H "DD-APPLICATION-KEY: $DD_APP_KEY" \
     "https://$DD_HOST/api/v1/dashboard" \
| jq '.dashboards | length'

The first call is the get all monitors endpoint, the second get all dashboards. Both need an application key as well as an API key, which is why a first attempt usually comes back 403.

Two numbers. We budget roughly twenty minutes per monitor and an hour per dashboard, plus a fortnight of both tools running side by side. Multiply it out before the next renewal call. If the answer is four weeks of platform engineering, that is a negotiating position. If it is four months, you have found out why the last two teams stayed.

Then check the estate the other way round: how many services already emit OpenTelemetry and how many are still on the proprietary tracer. That ratio is the only part of the number you can move this quarter.

When is staying instrumented the Datadog way the honest answer?

More often than a post like this usually admits.

If you are on the products OpenTelemetry does not cover, the trade is a capability you use for a capability you might use. If your estate is small enough that the whole rebuild is a week, the insurance costs more than the event it insures against. And if you have already committed for three years at a rate nobody will beat, portability work now buys an option you cannot exercise until the term ends. Do the cheap half, instrument new services with OpenTelemetry, and leave the rest alone.

The case changes when a regulator, a customer questionnaire or a renewal at double the rate puts a date on it. Having done nothing gets expensive, and it is the same shape as every other handover problem: cheap while you still have the people, dear once you do not. We wrote that out for outgoing vendors in what you should own when they leave.

The short version

Get the number first. Run the two API calls, multiply the counts, and put the result next to the price difference you were quoted. Most teams find the rebuild eats a quarter to half of the first year's saving, which turns the question from whether to switch into when.

Then do the three cheap things regardless of what you decide. New services get OpenTelemetry SDKs. Monitors and dashboards live in the repository beside the service. The compliance archive lives in your own bucket, not inside the tool. None of it requires you to leave, and all of it is work you would have to do anyway on the day you did.

And if the bill started this, cut it before you move rather than after. Benchmarking a new tool against your own waste hands you a saving that was never about the vendor. Most of it is visible from the estimate you should have built before signing.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.