Datadog vs JP1 - The Philosophical Difference Between Integrated Operations Management and SaaS Monitoring

Conclusion - Because the Scopes Are Asymmetric, First Separate "What to Move"

JP1 is Hitachi's "Integrated System Operations Management" product family, and its official site positions it as a solution covering on-premises / multi-cloud / hybrid environments that delivers not only integrated management and system monitoring but also business process integration and automation, endpoint management, backup, and security (as of September 2026, Source: JP1 Integrated System Operations Management). Datadog is an observability SaaS that gathers metrics / logs / traces into a single data platform, and job execution management and endpoint asset management are not within its scope. The two are not products competing for superiority on the same footing; they have an overlapping part (monitoring and notification) and a non-overlapping part (jobs / assets / distribution / backup). The first question in the evaluation is not "can JP1 be replaced by Datadog" but "of the work JP1 handles, which parts move to the Datadog side and which stay". Below, we set up three axes to use for that separation.

How the JP1 Product Family Is Organized

The product list on the official site is organized as product names under each functional category (as of September 2026, Source: JP1 Integrated System Operations Management). The "monitoring" that overlaps with Datadog corresponds to the categories of integrated management, performance management, network management, and notification management; the other categories have no corresponding Datadog product.

There is also one point about sales regions. The Products & Services page explicitly states that some JP1 products are sold only in Japan, and that JP1 Cloud Service and the IT operations optimization services are sold only in Japan (Source: Products & Services). If you want to view systems at overseas sites on the same platform, this is the first thing to verify.

Axis 1: What Sits at the Center of Operations

The first axis is what you place at the center of operations. Looking at the JP1 list, products that "run the business", such as job management (JP1/Automatic Job Management System 3), operations automation, and IT asset management, sit alongside monitoring. It is designed to manage everything from the execution order of overnight batches to endpoint distribution to backup success or failure within a single operations platform. Datadog's center is observing the internal state of systems: a platform for investigating "where and what happened" by tying Infrastructure Monitoring metrics, logs, and traces together with the same tags. This difference shows up in the "what happens next" after an anomaly is found by monitoring.

Therefore, if the center is "integrating business operations including batch success or failure and endpoint management", JP1's territory is wider, and if the center is "investigating the internal state of services that scale up and down in the cloud", Datadog's territory is wider. Read it not as which is superior, but as which one your own center of operations is closer to.

Axis 2: How Often Do Monitored Targets and Settings Change

The second axis is the frequency of change. There are three kinds of change, and the two are designed differently for each.

JP1's official site promotes "Operations as Code" and "operations integration" and also lists the SaaS offering JP1 Cloud Service, so it can be confirmed that it does position itself for environments with frequent change (as of September 2026, Source: JP1 Integrated System Operations Management). Where the judgment diverges is "who" makes the changes. If the operations department acts as the gatekeeper and applies changes in a planned way according to procedure documents, it is easier to build operations along the lines of an integrated operations management system; if development teams add monitoring for their own services themselves and change it several times a week, the SaaS type that makes it easy to delegate settings to each team has less friction. This is the axis for seeing whether the organization's structure and the product's design match.

Axis 3: How Costs Are Determined (The Units Differ, So the Numbers Are Not Compared)

The third axis is how costs are determined; because the units differ, the numbers are not compared. On its "Prices and Configuration Examples" page, Hitachi publishes the JP1 standard price list (Excel format) and configuration examples with approximate prices by category (PDF format), and directs inquiries for products not listed (as of September 2026, Source: Prices and Configuration Examples). Costs are of the product license type, determined by "which products, in which configuration, with how many licenses". Datadog publishes usage unit prices per SKU; Infrastructure Monitoring, for example, is a monthly amount per host (three unit prices: annual contract / monthly contract / on-demand), and the bill moves exactly as much as the targets increase or decrease (as of August 2026, Source: Datadog Pricing).

What you need to decide is which you are closer to: wanting to fix the configuration and lock in the annual budget, or wanting to pay only for what you use as targets increase and decrease. How the stacking is counted is covered in How to Decode the Pricing Structure. This article explains how billing works. For current unit prices and plans, refer to each vendor's official pricing page.

Conditions Suited to JP1 and Conditions Suited to Datadog

Converting the three axes into conditions, they can be contrasted as follows. The asymmetry of scope mentioned at the start is also laid out in the top 4 rows of the same table. Both columns are conditions each is "suited to", and do not mean the other cannot do it.

If 3 or more of the 4 rows of suited conditions lean to one side, the natural course is to start designing with that side at the center. If they split left and right, the realistic form is not "replacement" but the coexistence described in the next section. The concrete cost assessment when choosing Datadog (monthly cost by scale band, judgment by requirement) is covered by the Adoption Checklist; this article sits in the position of sorting out "is this even the right thing to compare against" before proceeding there.

The Shape of Coexistence and Three Things to Verify Before Migrating

The basic shape of coexistence is "keep business operations and integrated notification in JP1, move observation of cloud services to Datadog, and feed anomaly detections to the JP1 side". Hitachi's official site publishes, as a system operations hack on observability, "How to manage the flood of alerts notified by email centrally in JP1", so Hitachi itself demonstrates the practice of aggregating alerts from observation tools on the JP1 side (as of September 2026, Source: JP1 Integrated System Operations Management). The exit on the Datadog side is Monitors notifications, which can be passed externally by email or Webhook. Since JP1's official pages have no mention of an integration with Datadog, verify individually against the JP1 product specifications which path (email / Webhook / event ingestion) can receive them. There are three things to verify before deciding to migrate.

The decision moves faster if you treat the work of comparing against JP1 not as deciding which is superior, but as redrawing the map of your operations.