{"id":4065,"date":"2026-05-15T09:12:19","date_gmt":"2026-05-15T09:12:19","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/15\/migration-observability-measure-meaning-not-movement\/"},"modified":"2026-05-15T09:12:19","modified_gmt":"2026-05-15T09:12:19","slug":"migration-observability-measure-meaning-not-movement","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/15\/migration-observability-measure-meaning-not-movement\/","title":{"rendered":"Migration\u00a0Observability: Measure Meaning,\u00a0Not\u00a0Movement\u00a0"},"content":{"rendered":"
\"migration,<\/div>\n

\"migration,<\/p>\n

Engineering teams rarely fail migrations because they lack technical\u00a0skill. They fail because they measure movement when they should be measuring meaning.<\/span>\u00a0<\/span><\/p>\n

Record counts match. New deployments are up. The target control plane is serving traffic. The rollback switch still exists. None of that proves the platform is preserving meaning. It only\u00a0proves\u00a0the system is moving. On our multi-cloud team, that distinction was the difference between a migration that\u202f\u2018looked\u2019\u202fsuccessful and one that\u00a0actually was.<\/span>\u00a0<\/span><\/p>\n

Control planes are where this matters most<\/a>. A control plane decides what a resource means:\u00a0Which\u00a0downstream infrastructure it owns, which tenant it belongs to, what life\u00a0cycle\u00a0state\u00a0it\u2019s\u00a0in\u00a0and\u00a0which operations are safe to perform. If that meaning shifts during migration,\u00a0the failure\u00a0is rarely obvious at first. It\u00a0shows up\u00a0later as an incorrect cleanup, a broken lookup path, a missing telemetry flow, a downstream workflow acting on stale assumptions. By the time you notice the\u00a0symptom, the dashboards have been green for days.<\/span>\u00a0<\/span><\/p>\n

Migration observability\u00a0has to\u00a0be part of the migration design. Not\u00a0bolted on\u00a0after the switch-over plan is approved.\u00a0It\u2019s the mechanism that tells you whether the plan is actually preserving correctness.<\/span>\u00a0<\/span><\/p>\n

Record\u00a0Counts are Progress Signals, not Correctness Signals<\/span>\u00a0<\/span><\/h3>\n

Most migration dashboards start with the same familiar metrics: Records copied, requests served by the target, backlog depth, queue lag, and workflow completion counts. They tell you the migration is moving.<\/span>\u00a0<\/span><\/p>\n

They\u00a0don\u2019t\u00a0tell\u00a0you\u00a0it\u2019s\u00a0right.<\/span>\u00a0<\/span><\/p>\n

In\u00a0a control-plane migration, correctness lives in semantics. A resource record is only meaningful if the target control plane interprets it the same way the legacy one did. A\u00a0lookup\u00a0API is only compatible if the downstream system gets the same operational answer, not just a response with a similar shape, but one that means the same thing. A cleanup workflow is only safe if it reaches the same decision about shared infrastructure\u00a0that\u00a0the pre-migration system would have reached.<\/span>\u00a0<\/span><\/p>\n

\u2018All records copied\u2019 is rarely enough. In one of our migrations, old resources stayed in a legacy metadata store while new resources went to the target until a reconciliation workflow caught up. During that phase, record counts looked completely healthy while the operational truth was still split across both stores. We only realized the gap when a cleanup workflow made the wrong decision for a compartment that was \u2018empty\u2019 in one store but not the other. The record count metric had nothing to say about it.<\/span>\u00a0<\/span><\/p>\n

We were measuring\u00a0movement. We should have been measuring\u00a0meaning.<\/span>\u00a0<\/span><\/p>\n

Migrations\u00a0Need a Defined Idea of Drift<\/span>\u00a0<\/span><\/h3>\n

Traditional operational observability focuses on latency, errors,\u00a0throughput\u00a0and saturation. Migration observability needs a different category:\u00a0Semantic drift.<\/span>\u00a0<\/span><\/p>\n

Drift is the distance between what the legacy system means and what the target system currently means for the same logical resource or workflow decision. Ordinary service monitoring usually misses it. Requests still return 200. Workflows\u00a0complete. Consumers get answers. The answers may no longer mean the same thing.<\/span>\u00a0<\/span><\/p>\n

In a live control-plane migration, drift shows up in several forms:\u00a0A\u00a0resource exists in one store but not the other; the same resource is in both stores but one copy is newer; both copies have the same timestamp but different content; the target can answer a read but not with the semantics the legacy path used; shared infrastructure cleanup decisions differ depending on which store is consulted; a downstream component falls back to the legacy path more often than expected because parity hasn\u2019t converged.<\/span>\u00a0<\/span><\/p>\n

These are the signals that tell you whether the migration is still controlled or has started drifting.<\/span>\u00a0<\/span><\/p>\n

We started treating drift as a first-class metric after a cleanup workflow made the wrong decision based on an incomplete view of active resources. Before that, we tracked progress. After, we tracked the meaning. I\u2019m still not sure we have the right drift metrics for every scenario. It\u2019s an evolving practice. But the shift in mindset was worth it on its own.<\/span>\u00a0<\/span><\/p>\n

Drift\u00a0Budgets Make Cutover Decisions Defensible<\/span>\u00a0<\/span><\/h3>\n

In SRE, error budgets\u00a0turn\u00a0a subjective question\u00a0(Does this feel stable enough?)\u00a0into an operational contract. The same logic works for migration\u00a0drift. A drift budget says how much semantic divergence the platform is willing to tolerate at each phase.<\/span>\u00a0<\/span><\/p>\n

Early in a migration, the budget may allow some controlled mismatch. Dual reads are still enabled. The reconciliation workflow is expected to copy records for a while. Fallback reads may be normal. Later, tolerated\u00a0drift\u00a0should shrink. By the time the target control\u00a0plane is primary for\u00a0provisioning\u00a0and rollback risk is being reduced, the budget should be tight enough that unresolved differences are blockers, not background noise.<\/span>\u00a0<\/span><\/p>\n

This changes how cutover conversations go. Instead of\u00a0\u2018the dashboards look good\u2019\u00a0or\u00a0\u2018the sync job seems caught up\u2019, the team can say:\u00a0Fallback read rate is below threshold, reconciliation updates have converged, no cleanup-invariant violations observed, parity checks show no unresolved mismatches in the active resource set.\u00a0On our team, adopting this checklist moved cutover decisions from\u00a0\u2018I think we\u2019re ready\u2019\u00a0to something we could actually defend in a review.<\/span>\u00a0<\/span><\/p>\n

Without a drift budget, migrations are governed by intuition. Intuition has a place in distributed systems, but\u00a0it\u2019s\u00a0a poor substitute for measured convergence, especially at 3\u00a0a.m.,\u00a0when someone is asking whether to\u00a0proceed\u00a0or roll back.<\/span>\u00a0<\/span><\/p>\n

Parity\u00a0has to be Shaped to the Domain<\/span>\u00a0<\/span><\/h3>\n

\u2018Parity\u2019\u00a0gets used often in migrations.\u00a0It\u2019s\u00a0only useful when tied to what matters in the specific system.<\/span>\u00a0<\/span><\/p>\n

A multi-cloud observability control plane\u00a0doesn\u2019t\u00a0need generic record parity. It needs operational parity.<\/span>\u00a0<\/span><\/p>\n

Can the unified control plane resolve the same monitored resource to the same provider-visible target\u00a0that\u00a0the legacy one would have resolved? Does a lookup that now requires compartment context still preserve the meaning downstream components depend on? When a cleanup workflow evaluates whether shared service connectors or managed rules can be removed, does it reason over the full active set or just the locally visible one? When a resource exists in both stores, does reconciliation keep the one that preserves the correct life\u00a0cycle state?<\/span>\u00a0<\/span><\/p>\n

Behavior checks. Not formatting checks.<\/span>\u00a0<\/span><\/p>\n

A useful parity model breaks into three areas:\u00a0Behavioral\u00a0parity (the system takes the same action or returns the same effective result for the same logical resource), life\u00a0cycle parity (create, active and delete meaning is preserved, especially where cleanup safety or rollback depends on it) and authority parity (the system respects the current migration phase, so if a record is supposed to remain readable through fallback until reconciliation completes, parity isn\u2019t just\u00a0\u2018record exists in target\u2019\u00a0but\u00a0\u2018the platform still gives the intended answer at this phase\u2019).<\/span>\u00a0<\/span><\/p>\n

Our first parity definition was too loose. We checked record existence and field equality but not operational equivalence.\u00a0The day we added behavioral parity checks was the day our\u00a0migration dashboard started telling us things we could actually act on.\u00a0Before that, it was mostly reassuring. Reassuring\u00a0isn\u2019t\u00a0the same as informative.<\/span>\u00a0<\/span><\/p>\n

Dual\u00a0Reads Need to be Observable, Not Hidden<\/span>\u00a0<\/span><\/h3>\n

Dual reads are common in migrations because they let the target path serve traffic while falling back to the legacy path when necessary. Useful. Dangerous when invisible.<\/span>\u00a0<\/span><\/p>\n

A migration should know, at all times:\u00a0How often the primary read succeeds on the target; how often fallback to the legacy path is still required; which resource categories still rely on fallback; whether fallback behavior is shrinking as expected; whether fallback is happening because parity hasn\u2019t converged or because an API contract changed in a way the target path doesn\u2019t yet satisfy.<\/span>\u00a0<\/span><\/p>\n

This matters because dual reads can create a false sense of readiness. Traffic flows, so the migration looks successful. But the target may still depend heavily on the old system for correctness. If observability\u00a0doesn\u2019t\u00a0surface that dependency, the team can disable rollback support or turn off legacy reads too early.<\/span>\u00a0<\/span><\/p>\n

Dual-read telemetry should be a top-level migration metric.<\/span>\u00a0<\/span><\/p>\n

In practice, it becomes one of the clearest convergence indicators. A healthy migration shows fallback trending down as reconciliation catches up. If fallback stays flat or spikes after switch-over, the migration has moved traffic faster than it has moved meaning. We saw exactly that pattern once. Fallback plateaued at about 15% for a specific resource class. The target lookup path was returning a subtly different answer for resources with compartment-level dependencies. The dual-read metric told us. The rest of our monitoring\u00a0didn\u2019t. We would have disabled legacy reads and broken those lookups without it.<\/span>\u00a0<\/span><\/p>\n

Reconciliation\u00a0Workflows Need Their Own\u00a0Telemetry Contract<\/span>\u00a0<\/span><\/h3>\n

A periodic sync job\u00a0isn\u2019t\u00a0enough.\u00a0A migration needs to know what the job is actually doing.<\/span>\u00a0<\/span><\/p>\n

For a reconciliation workflow that copies records from a legacy store to a target store, useful signals include:\u00a0Source records scanned; missing target records created; target records replaced because source was newer; target records preserved because target was newer; equal-timestamp records that matched exactly; equal-timestamp records that did not match, which is an invariant failure; cycles with no new effective changes.<\/span>\u00a0<\/span><\/p>\n

These tell you whether the sync path is converging or churning.<\/span>\u00a0<\/span><\/p>\n

This matters even more when only one sync direction should run at a time. If forward sync and rollback sync are both\u00a0possible\u00a0but only one is supposed to be active, telemetry needs\u00a0to make that visible.\u00a0Otherwise,\u00a0the platform can end up with two sides rewriting each other under the banner of\u00a0\u2018reconciliation\u2019.\u00a0We almost hit this during a rollback test. The metric that caught it was the\u00a0\u2018records replaced\u2019\u00a0counter going up on both sides in the same time window.<\/span>\u00a0<\/span><\/p>\n

Phase-aware\u00a0monitoring\u00a0matters\u00a0too. Early on, frequent new-record additions may be normal. Later, the expected pattern shifts toward no-op cycles and exact matches. The meaning of the metric changes with the migration stage. Good observability reflects that shift instead of flattening all activity into a single\u00a0\u2018records processed\u2019\u00a0number.<\/span>\u00a0<\/span><\/p>\n

Cleanup\u00a0Safety Needs Dedicated Visibility<\/span>\u00a0<\/span><\/h3>\n

If service connectors, managed rules or similar shared resources are provisioned per compartment and reused across multiple logical resources, cleanup\u00a0isn\u2019t\u00a0a per-record operation.\u00a0It\u2019s\u00a0a decision scoped to the active set in that compartment. During migration, that active set may be split across stores.<\/span>\u00a0<\/span><\/p>\n

The system has to answer: Did the cleanup workflow check both legacy and target sources? How many active dependents were found in each? Was the cleanup skipped because a dependent remained? How often would a single-store decision have produced the wrong outcome? Were any cleanup actions taken during periods when dual-store reasoning was still required?<\/span>\u00a0<\/span><\/p>\n

On our team, this was where a superficially successful cutover nearly became a customer-facing incident. Shared infrastructure was about to be removed because the target store looked empty, while the legacy store still had active resources. We caught it because we had added cross-store dependency checks to the cleanup path.<\/span>\u00a0<\/span><\/p>\n

Cleanup-safety\u00a0signals now live\u00a0in\u00a0our top-level migration dashboard. The lesson:\u00a0Any shared-infrastructure cleanup during migration needs its own telemetry, separate from general workflow monitoring. If the observability layer\u00a0can\u2019t\u00a0distinguish between\u00a0\u2018compartment is genuinely empty\u2019\u00a0and\u00a0\u2018compartment looks empty from one\u00a0store\u2019s\u00a0perspective\u2019,\u00a0the most important life\u00a0cycle guarantee\u00a0isn\u2019t\u00a0being measured.<\/span>\u00a0<\/span><\/p>\n

Cloud-Specific\u00a0Visibility Matters in a Unified Control Plane<\/span>\u00a0<\/span><\/h3>\n

One of the promises of convergence:\u00a0Fewer deployments, less duplicated code, real\u00a0value. But once one control plane serves multiple CSP integrations, telemetry\u00a0has to\u00a0preserve cloud-specific visibility.<\/span>\u00a0<\/span><\/p>\n

If\u00a0request\u00a0traffic, errors, fallback rates, reconciliation\u00a0events\u00a0and cleanup decisions are all emitted without cloud context, a unified deployment blurs the signals operators need. One\u00a0provider\u00a0path may be fully converged while another still depends heavily on fallback. One cloud-specific lookup flow may be stable while another has unresolved parity issues.<\/span>\u00a0<\/span><\/p>\n

Migration observability in a unified control plane needs enough dimensionality to answer:\u00a0Which\u00a0cloud path is healthy, which feature flags are active, which resource class is still\u00a0reconciling\u00a0and which signals belong to which provider context.<\/span>\u00a0<\/span><\/p>\n

We learned this the hard way. An issue specific to one provider\u2019s lookup path was masked by healthy aggregate metrics from the other two. Everything looked fine in aggregate. One provider\u00a0was broken. We started tagging every migration metric with cloud type after that.<\/span>\u00a0<\/span><\/p>\n

Tracing Matters Because Cutovers Fail on Explanation Time<\/span>\u00a0<\/span><\/h3>\n

When a migration issue surfaces, the worst outcome\u00a0isn\u2019t\u00a0always the bug itself.\u00a0Often\u00a0it\u2019s\u00a0how long it takes to explain the bug.<\/span>\u00a0<\/span><\/p>\n

Which endpoint\u00a0served\u00a0the request? Which feature-flag state was active? Did the lookup hit the target first and then fall back? Which store supplied the resource? Which converter path ran? Did reconciliation update the target record before or after the workflow decision? Did cleanup evaluate one source or both?<\/span>\u00a0<\/span><\/p>\n

Without structured traces or strongly correlated logs, these questions become an incident review project instead of an operational response.<\/span>\u00a0<\/span><\/p>\n

A good migration trace reconstructs the full decision path: Request enters through the target control plane, dual read is enabled, target lookup misses, fallback succeeds from the legacy source, response returns, reconciliation later copies the record, subsequent reads resolve natively, and cleanup stays blocked because a dependent still exists in the alternate store. When the system can show that path quickly, rollback or mitigation becomes operationally realistic.<\/span>\u00a0<\/span><\/p>\n

During migration, time to explanation is often as important as time to recovery.<\/span>\u00a0<\/span><\/p>\n

A Cutover is a Measured Progression, not a Moment<\/span>\u00a0<\/span><\/h3>\n

The cleanest migration diagrams show cutover as a switch:\u00a0Before and after, old and new. Real cutovers are messier.<\/span>\u00a0<\/span><\/p>\n

Provisioning traffic may switch before all historical metadata is copied. Lookup consumers may move to a new API shape while keeping fallback to the old path. Reverse sync may stay disabled until rollback is needed. Legacy workflows may need to complete work they have already accepted. Some regions may migrate before others. Preproduction may show healthy parity while a production slice still requires whitelisted tenant validation.<\/span>\u00a0<\/span><\/p>\n

A strong migration observability model follows that sequence:\u00a0Dual-read enablement becomes visible; target-read success rate rises; provisioning traffic shifts; reconciliation reduces active divergence; cleanup safety stays enforced across both stores; rollback readiness stays intact until convergence criteria are met. Only\u00a0then do dual reads or reverse paths get reduced.<\/span>\u00a0<\/span><\/p>\n

Mapping this sequence and building a dashboard that tracked where we were in it was one of the most useful things we did. It took the mystery out of cutover readiness. It also made it clear when we\u00a0weren\u2019t\u00a0ready.<\/span>\u00a0<\/span><\/p>\n

Migration Observability Makes No-Downtime Claims Credible<\/span>\u00a0<\/span><\/h3>\n

Many migrations aspire to be no-downtime. Reasonable goal. Easy to overstate if the only evidence is service availability.<\/span>\u00a0<\/span><\/p>\n

A no-downtime control-plane migration\u00a0isn\u2019t\u00a0just one where the API stayed up.\u00a0It\u2019s\u00a0one where the platform preserved the meaning of its operations throughout the transition:\u00a0Resources\u00a0remained discoverable, shared infrastructure\u00a0wasn\u2019t\u00a0cleaned up prematurely, downstream systems continued receiving the correct mappings and rollback stayed possible until convergence was real rather than assumed.<\/span>\u00a0<\/span><\/p>\n

None of that can be\u00a0established\u00a0through generic\u00a0service\u00a0health. It takes drift-aware metrics, domain-shaped parity checks, dual-read telemetry, reconciliation metrics, cloud-specific dimensions, cleanup-safety\u00a0monitoring\u00a0and traces that explain decision paths.<\/span>\u00a0<\/span><\/p>\n

After three migrations with this approach, I can say:\u00a0The\u00a0telemetry work was always the part we underestimated, and always the part that mattered most. Measure meaning, not movement. The dashboards that track whether your system is doing the right thing are harder to build than the ones that track whether\u00a0it\u2019s\u00a0doing anything at all.\u00a0They\u2019re\u00a0also the ones that let you sleep.<\/span>\u00a0<\/span><\/p>\n

Key Takeaways<\/span>\u00a0<\/span><\/h3>\n
    \n
  1. Record counts and service availability are progress signals, not correctness signals. A migration can look healthy on every standard dashboard while silently drifting on semantics.<\/span>\u00a0<\/span><\/li>\n
  2. Semantic drift (the distance between what the legacy system means and what the target currently means for the same resource) deserves to be treated as a first-class telemetry entity, not a debug afterthought.<\/span>\u00a0<\/span><\/li>\n
  3. Drift budgets, borrowed from SRE error-budget thinking, turn vague cutover intuition into a measurable contract: How much divergence is tolerable at each phase, and when it must reach zero.<\/span>\u00a0<\/span><\/li>\n
  4. Dual-read telemetry, reconciliation\u00a0metrics\u00a0and cleanup-safety signals belong at the top of your migration dashboard, not buried in logs nobody reads until something breaks.<\/span>\u00a0<\/span><\/li>\n
  5. In unified control planes serving multiple cloud integrations, observability\u00a0has to\u00a0preserve cloud-specific dimensions, or one broken\u00a0provider\u00a0path disappears into healthy aggregate numbers.<\/span><\/li>\n<\/ol>\n

    Read More<\/a><\/p>\n

    \u200b<\/p>","protected":false},"excerpt":{"rendered":"

    Engineering teams rarely fail migrations because they lack technical\u00a0skill. They fail because they measure movement when they should be measuring […]<\/p>\n","protected":false},"author":1,"featured_media":4066,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4065","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4065","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4065"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4065\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4066"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}