Configuration migration fallbacks

When configuration structures evolve, implement fallback mechanisms to handle both old and new formats gracefully. This ensures backward compatibility during transitions and prevents breaking changes.

Key practices:

• Check for new configuration format first, then fall back to legacy format
• Update conversion logic when units or data types change
• Provide clear migration paths for deprecated configuration options

Example from query configuration migration:

// Check new format first, then fallback to legacy
metricName: queryData.aggregation?.[0].metricName || queryData.aggregateAttribute?.key

Example from TTL configuration update:

// Handle unit conversion during configuration migration
setLogsCurrentTTLValues((prev) => ({
  ...prev,
  logs_ttl_duration_hrs: logsTotalRetentionPeriod || -1,
  default_ttl_days: logsTotalRetentionPeriod 
    ? logsTotalRetentionPeriod / 24 // convert Hours to days
    : prev.default_ttl_days
}));

This approach maintains system stability while allowing configuration schemas to evolve over time.