Backstage vs Port: Portales Internos de Desarrollador IDP (2026)

Matriz Estratégica de Decisión por Tamaño de Organización:

Team Topologies y el Camino Pavimentado (Golden Path)

Apoyándose en el marco estratégico propuesto por Matthew Skelton y Manuel Pais en su obra Team Topologies, las organizaciones tecnológicas maduras estructuran sus recursos dividiendo responsabilidades entre Equipos Orientados al Flujo (Stream-Aligned Teams), enfocados en el producto de negocio, y un Equipo de Plataforma (Platform Team), cuya misión consiste en tratar la infraestructura interna como un producto. El propósito del equipo de plataforma no reside en imponer normativas rígidas, sino en asfaltar un Camino Pavimentado o Golden Path: una autopista operativa que convierte la vía segura, estandarizada y económica en la vía más sencilla para desplegar código.

El Portal Interno de Desarrollador (IDP) se erige como la interfaz humana y el motor operativo de este Golden Path, resolviendo cuatro desafíos fundamentales:

• Catálogo Unificado de Software: Un inventario fidedigno que registra cada microservicio, API, recurso de nube, base de datos y documentación, junto con su equipo responsable y sus dependencias técnicas.
• Autoservicio Automatizado para Desarrolladores: La capacidad de aprovisionar nuevos microservicios con plantillas homologadas, instanciar entornos efímeros de pruebas o solicitar accesos temporales mediante formularios interactivos sin recurrir a tickets de Jira.
• Gobernanza y Scorecards de Calidad: La medición objetiva y gamificada de la madurez de los servicios, cobertura de pruebas, parches de seguridad y directrices de arquitectura.
• Gestión Centralizada del Conocimiento (Docs-Like-Code): La integración de runbooks operativos, diagramas de arquitectura y contratos de APIs junto a la definición del propio servicio.

Anatomía del Monorepo de Backstage y Topología de Componentes

• Aplicación Frontend (packages/app): Una SPA (Single Page Application) en React 18 construida sobre Material UI (históricamente MUI v4, atravesando una compleja transición comunitaria hacia MUI v5). Actúa como un contenedor donde se montan extensiones y rutas de plugins. Cada nuevo plugin requiere ser importado en código fuente TypeScript, configurado en el enrutador y compilado mediante Webpack.
• Servicio Backend (packages/backend): Un proceso en Node.js que tradicionalmente utilizaba routers de Express y actualmente migra al "New Backend System" de Backstage. Este nuevo sistema incorpora inyección de dependencias formal, referencias a servicios del núcleo (coreServices.logger, coreServices.database, coreServices.auth) y registro modular de plugins mediante backend.add().
• Motor de Persistencia: Backstage recurre a knex.js como constructor de consultas SQL. Aunque incluye SQLite para entornos de prueba locales, cualquier entorno de producción exige una base de datos relacional robusta, fundamentalmente PostgreSQL (como AWS RDS PostgreSQL o Google Cloud SQL). En ella residen las ubicaciones de entidades, esquemas procesados, claves foráneas y el índice de búsqueda.
• Ciclo de Compilación y Despliegue: El ciclo de vida de Backstage implica compilar TypeScript a JavaScript, generar bundles estáticos con Webpack, construir una imagen Docker multietapa, empujarla a un registro de contenedores (ECR, Artifact Registry) y orquestar réplicas en Kubernetes vía Helm charts.

Arquitectura del Sistema Port y Bus de Sincronización en Tiempo Real

• Plano de Control SaaS Distribuido: El núcleo de Port está estructurado sobre un bus de streaming de eventos de alto rendimiento operado con Apache Kafka. Todas las mutaciones de entidades y cambios de estado se publican en particiones de Kafka, permitiendo procesamiento asíncrono desacoplado, reconciliación de estado y transmisión reactiva a la interfaz vía WebSockets y Server-Sent Events (SSE).
• El Framework de Integración Ocean: Port liberó bajo código abierto el framework Ocean (desarrollado en Python y Go), que estandariza la creación de exportadores de datos. Ocean incluye de forma nativa políticas de reintento con retroceso exponencial (exponential backoff), control de límites de tasa (rate limiting) y sincronización de deltas.
• Exportadores Híbridos en VPC (Data Plane): Los agentes exportadores se despliegan mediante Helm charts (en Kubernetes), funciones AWS Lambda o GitHub Apps. El exportador de Kubernetes se ejecuta dentro del cluster del cliente, registra Kubernetes Informers contra el API server local, monitoriza eventos de recursos (Pods, Deployments, CRDs, Ingresses) y envía únicamente deltas cifrados de metadatos mediante conexiones salientes HTTPS/TLS hacia Port.
• Motor de Grafo y Búsqueda: Por debajo de las APIs, Port mantiene un índice topológico relacional acoplado a un cluster de Elasticsearch/OpenSearch. Esto permite ejecutar consultas complejas sobre grafos de dependencias (por ejemplo: identificar qué microservicios consumen una base de datos Aurora concreta con vulnerabilidades críticas abiertas en Snyk) en cuestión de milisegundos.

Comparativa Arquitectónica: Polling Periódico vs Streaming de Eventos

La divergencia estructural más profunda entre ambas soluciones se sintetiza en su paradigma de comunicación. Backstage se fundamenta en un modelo pull de sondeo por lotes (polling): procesos en segundo plano inspeccionan los repositorios Git periódicamente, parsean YAMLs y escriben en PostgreSQL en ciclos de 10 a 30 minutos. Por el contrario, Port opera bajo un modelo push orientado a eventos en tiempo real: cada vez que un pod de Kubernetes se reinicia, un PR se fusiona en GitHub o un workspace de Terraform aplica cambios, el evento se emite de inmediato al bus Kafka de Port, actualizando el catálogo en menos de 5 segundos.

Las Cinco Patologías Operativas del Catálogo GitOps en Backstage:

1. El Cuello de Botella de la Actualización Humana: Cuando un equipo refactoriza un microservicio o migra una base de datos, rara vez recuerda actualizar el fichero estático catalog-info.yaml. En pocas semanas, el catálogo diverge de la infraestructura real desplegada.
2. Entidades Fantasma y Bitrot de Repositorios: Cuando un repositorio se archiva, renombra o elimina, el procesador de Backstage suele retener la entidad huérfana a menos que se invoque manualmente un proceso de desregistro. Con miles de repositorios, los resultados de búsqueda se contaminan de servicios inexistentes.
3. Rigidez del Modelo de Datos: Incorporar un nuevo tipo de entidad (como KubernetesCluster, FeatureFlag, DatadogMonitor o CentroDeCoste) exige escribir esquemas TypeScript personalizados, programar procesadores en el backend del monorepo y ejecutar migraciones de base de datos.
4. Saturación de Límites de Tasa (Rate Limiting) en APIs de Git: Para descubrir cambios, Backstage sondea periódicamente las APIs de GitHub o GitLab. En empresas con más de 2,000 repositorios, estos bucles agotan los límites de llamadas por hora, provocando que la sincronización del catálogo se congele.
5. Carencia de Contexto de Infraestructura en Tiempo Real: Un fichero estático YAML no puede reflejar si un microservicio está sufriendo caídas en Kubernetes (CrashLoopBackOff) o cuál es su gasto en la nube hoy. Backstage debe recurrir a plugins de frontend que consultan APIs externas desde el navegador de cada usuario, ralentizando la navegación.

Capacidades de los Blueprints de Port y Topología Relacional

En Port, los ingenieros de plataforma pueden configurar Blueprints en minutos desde la interfaz o mediante Terraform y APIs:

• Blueprints para Cualquier Activo: Permite modelar Microservicio, DeploymentK8s, InstanciaRDS, BucketS3, TopicoKafka, WorkspaceTerraform, ServicioPagerDuty o ProyectoJira.
• Propiedades Dinámicas y Cálculos: Admite campos de texto, booleanos, números, arrays, objetos JSON y estados. Soporta Propiedades Calculadas que agregan datos de entidades hijas en tiempo real (por ejemplo, calcular el gasto mensual consolidado sumando los costes de los recursos cloud asociados).
• Relaciones Bidireccionales de Grafo: Conexiones relacionales nativas (1 a 1, 1 a muchos, muchos a muchos): un Microservicio se vincula a múltiples DeploymentK8s, que se asocian a un ClusterK8s, el cual depende de una CuentaAWS vinculada a una UnidadDeNegocio.
• Sincronización Automática sin Ficheros YAML: Cero intervención manual de los desarrolladores. El exportador de Kubernetes monitoriza los recursos nativos y sincroniza réplicas e imágenes en menos de 3 segundos, eliminando por completo la deriva documental.

Ciclo de Vida del Scaffolder de Backstage y Limitaciones Operativas

• Diseño de Plantillas: Los ingenieros de plataforma redactan plantillas con motores como Cookiecutter o Nunjucks, almacenadas en Git, que definen nombres de servicio, equipo responsable y parámetros base.
• Acciones Predeterminadas: Backstage provee acciones nativas básicas: fetch:template, fetch:plain, publish:github, publish:gitlab y catalog:register.
• Complejidad para Acciones a Medida: Si se requiere invocar una API interna, ejecutar Terraform o interactuar con un CLI propietario, es obligatorio programar un módulo en TypeScript implementando la interfaz createTemplateAction, recompilar el monorepo y desplegar una nueva versión del contenedor.
• Riesgos en el Entorno de Ejecución: Por defecto, los pasos del Scaffolder se ejecutan dentro del mismo proceso de Node.js en el pod del backend de Backstage. Ejecutar scripts de plantillas en el pod central del portal compromete la seguridad y la estabilidad. Delegar tareas a pods efímeros aislados en Kubernetes es posible, pero añade una complejidad notable de configuración.
• Inexistencia de Aprobaciones Jerárquicas Nativas: El núcleo de Backstage no ofrece flujos de aprobación. Si una acción exige autorización de un responsable de seguridad o de finanzas (como crear una base de datos en producción), el equipo debe construir plugins propios o integrar tickets externos en Jira.

Arquitectura de Autoservicio en Port y Ventajas Operativas

• Formularios Dinámicos Conectados al Catálogo: Los campos desplegables pueden consultar en vivo el grafo de entidades de Port mediante expresiones JQ. Por ejemplo, al solicitar un clonado de base de datos, el formulario solo muestra las instancias RDS activas del equipo solicitante en la región seleccionada.
• Flujos de Aprobación Nativos Multi-Etapa: Incorporados de serie. Las acciones pueden requerir aprobación por roles específicos. Los aprobadores reciben tarjetas interactivas en Slack o Microsoft Teams con botones de "Aprobar" o "Rechazar" en un clic e introducción de comentarios obligatorios.
• Disparadores Universales de Ejecución: Port no ejecuta código en sus servidores. Tras la aprobación, emite una señal cifrada al sistema elegido: un evento workflow_dispatch en GitHub Actions, un pipeline de GitLab CI, un workflow en Argo Workflows o un Webhook HTTP.
• Control de Acceso Granular (RBAC): Permite restringir la visibilidad y ejecución de acciones según el usuario, pertenencia a equipos o propiedades de la entidad (los juniors pueden reiniciar pods de staging; solo los Tech Leads pueden alterar réplicas en producción).
• Auditoría Integral de Operaciones: Cada invocación queda registrada con telemetría completa: identidad del solicitante, parámetros ingresados, marcas de tiempo de aprobación y enlace directo al pipeline externo con seguimiento de estado en vivo.

Mecánicas del Motor de Scorecards e Iniciativas en Port

• Niveles de Madurez Gamificados: Permite configurar categorías de excelencia (Bronce, Plata, Oro, Platino) por cada Blueprint. Los microservicios ascienden o descienden automáticamente según el cumplimiento de reglas.
• Evaluación Multidominio Cruzada: Las reglas combinan condiciones de múltiples integraciones. Por ejemplo, para alcanzar el Nivel Oro:
  • Repositorio: Protección de rama main activa, README.md presente, Quality Gate de SonarQube superado.
  • Seguridad: Cero vulnerabilidades críticas o altas en Snyk, alertas de Dependabot activas.
  • Kubernetes: Límites de CPU y memoria configurados explícitamente, réplicas mínimas ≥ 2, Pod Disruption Budget definido.
  • Operaciones: Política de escalado de guardia vinculada en PagerDuty, monitor de SLO en Datadog activo.
• Gestión de Iniciativas con Fechas Límite: Cuando la dirección técnica decreta una migración organizativa (ejemplo: "Migrar todos los microservicios a Node.js 20 antes del Q3"), se define una Iniciativa con fecha límite. Port monitoriza el porcentaje de adopción por equipo, proyecta el avance en paneles directivos y envía notificaciones automáticas por Slack a los servicios rezagados.

Modelos de Generación en TechDocs: Local vs CI/CD Externo

• Generación Local bajo Demanda: Cuando un usuario accede a una página documental, el backend de Backstage clona el repositorio Git, levanta un contenedor Docker efímero con Python MkDocs, compila el Markdown a HTML/CSS y lo sirve en el navegador. En entornos reales, esto causa picos brutales de CPU, latencias de carga inaceptables (de 15 a 40 segundos) y riesgo de saturación de memoria en Kubernetes.
• Generación Externa en CI/CD: En despliegues empresariales serios, la plataforma debe configurar pipelines externos (en GitHub Actions o GitLab CI) con @techdocs/cli. Tras cada commit, el pipeline compila MkDocs y sube los ficheros estáticos a un bucket de almacenamiento en la nube (AWS S3, Google Cloud Storage). Backstage se limita a leer y renderizar como proxy. Aunque rápido, exige mantener flujos de CI en cientos de repositorios.

Anatomía de una Actualización de Versión en Backstage

La ejecución periódica de un salto de versión (yarn backstage-cli versions:bump) desata con frecuencia una reacción en cadena de fallos:

1. Cambios Incompatibles en Firmas TypeScript: Las versiones intermedias del núcleo de Backstage modifican con frecuencia interfaces de programación, obligando a refactorizar componentes propios de frontend y el registro de plugins en el backend.
2. Obsolescencia de Plugins Comunitarios (Bitrot): Una instalación corporativa típica integra entre 10 y 25 plugins desarrollados por la comunidad (Argo CD, Datadog, Snyk). Cuando Backstage actualiza dependencias clave (como React 18 o el New Backend System), aquellos plugins no actualizados por sus creadores rompen el proceso de compilación. El equipo interno debe forzar forks en GitHub, corregir el código y mantener las versiones parcheadas indefinidamente.
3. Gestión Continua de Vulnerabilidades (CVEs): Un monorepo de Backstage acumula entre 1,500 y 2,500 dependencias transitivas de npm. Las alertas semanales de Dependabot relativas a fallos críticos exigen análisis, pruebas de regresión y continuos ciclos de despliegue.
4. Asignación Permanente de FTEs: Estadísticas consolidadas del sector confirman que sostener Backstage en organizaciones de 250 a 500 ingenieros requiere entre 2 y 4 ingenieros sénior de plataforma a tiempo completo (FTEs) dedicados en exclusiva al mantenimiento de fontanería técnica.

Ecuaciones Matemáticas del Coste Total de Propiedad de un IDP

Hipótesis de Partida: Salario bruto total anual de un ingeniero sénior de plataforma fijado en $180,000 USD en mercados internacionales consolidados (con adaptación a hubs hispanos detallada a continuación). Horizonte temporal de análisis: 36 meses.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-processing-service
  description: Motor de transacciones de alto rendimiento para liquidaciones multidivisa.
  tags:
    - java
    - spring-boot
    - payments
    - pci-dss
  annotations:
    backstage.io/techdocs-ref: dir:.
    github.com/project-slug: enterprise-corp/payment-service
    kubernetes.io/api-version: apps/v1
    kubernetes.io/kind: Deployment
    kubernetes.io/name: payment-processor
    backstage.io/kubernetes-id: payment-processor
    pagerduty.com/integration-key: os.environ.get("PAGERDUTY_KEY")
    snyk.io/project-id: 9a7b5c3d-4e2f-1a8b-0c9d-8e7f6a5b4c3d
    sonarqube.org/project-key: enterprise:payment-service
spec:
  type: service
  lifecycle: production
  owner: group:payment-platform-squad
  system: payments-ecosystem
  subcomponentOf: financial-ledger-core
  providesApis:
    - payment-settlement-v2-api
  consumesApis:
    - currency-conversion-v1-api
    - fraud-detection-v3-api
  dependsOn:
    - resource:payment-aurora-postgres
    - resource:transaction-events-kafka-topic

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: spring-boot-microservice-template
  title: Microservicio Spring Boot 3 de Producción
  description: Genera un servicio Java 21 homologado con OpenTelemetry, manifiestos K8s y CI.
  tags:
    - java
    - spring-boot
    - microservice
spec:
  owner: group:platform-engineering
  type: service
  parameters:
    - title: Especificación del Servicio
      required:
        - serviceName
        - ownerTeam
        - javaVersion
      properties:
        serviceName:
          title: Identificador del Servicio
          type: string
          description: Nombre único en formato kebab-case.
          pattern: '^[a-z0-9-]+$'
        ownerTeam:
          title: Equipo Responsable (Squad)
          type: string
          description: Equipo a cargo del mantenimiento y guardia on-call.
          ui:field: OwnerPicker
        javaVersion:
          title: Versión de JDK
          type: string
          default: '21'
          enum:
            - '17'
            - '21'
    - title: Repositorio Destino
      required:
        - repoUrl
      properties:
        repoUrl:
          title: Repositorio GitHub Destino
          type: string
          ui:field: RepoUrlPicker
          ui:options:
            allowedHosts:
              - github.com
  steps:
    - id: template
      name: Renderizar Plantilla de Código
      action: fetch:template
      input:
        url: ./skeleton
        values:
          serviceName: ${{ parameters.serviceName }}
          ownerTeam: ${{ parameters.ownerTeam }}
          javaVersion: ${{ parameters.javaVersion }}

    - id: publish
      name: Publicar en GitHub
      action: publish:github
      input:
        allowedHosts: ['github.com']
        description: Microservicio estandarizado ${{ parameters.serviceName }}
        repoUrl: ${{ parameters.repoUrl }}
        defaultBranch: main

    - id: register
      name: Registrar en Catálogo Backstage
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: '/catalog-info.yaml'
  output:
    links:
      - title: Repositorio de Código
        url: ${{ steps.publish.output.remoteUrl }}
      - title: Registro en Catálogo
        icon: catalog
        entityRef: ${{ steps.register.output.entityRef }}

{
  "identifier": "microservice",
  "title": "Microservicio",
  "icon": "Microservice",
  "schema": {
    "properties": {
      "language": {
        "title": "Lenguaje de Programación",
        "type": "string",
        "enum": ["Java", "Go", "TypeScript", "Python", "Rust"]
      },
      "framework": {
        "title": "Framework",
        "type": "string"
      },
      "pci_dss_scope": {
        "title": "Aplica Regregulación PCI-DSS",
        "type": "boolean",
        "default": false
      },
      "daily_cost_usd": {
        "title": "Coste Cloud Diario ($)",
        "type": "number",
        "description": "Agregado vía integración AWS Cost Explorer"
      },
      "oncall_engineer": {
        "title": "Ingeniero On-Call",
        "type": "string",
        "format": "user"
      }
    },
    "required": ["language"]
  },
  "relations": {
    "deployments": {
      "title": "Deployments en Kubernetes",
      "target": "k8s_deployment",
      "required": false,
      "many": true
    },
    "databases": {
      "title": "Bases de Datos Asociadas",
      "target": "cloud_database",
      "required": false,
      "many": true
    },
    "team": {
      "title": "Equipo Propietario",
      "target": "team",
      "required": true,
      "many": false
    }
  }
}

{
  "identifier": "rollback_database_migration",
  "title": "Rollback de Migración en Base de Datos de Producción",
  "icon": "DatabaseRollback",
  "trigger": "manual",
  "blueprint": "cloud_database",
  "requiredApproval": true,
  "approvalWebhook": {
    "url": "https://api.getport.io/v1/actions/approvals",
    "method": "POST"
  },
  "userInputs": {
    "properties": {
      "target_migration_version": {
        "title": "Versión de Migración Objetivo",
        "type": "string",
        "description": "Tag de versión de Flyway / Liquibase para retroceder"
      },
      "justification": {
        "title": "Justificación del Incidente",
        "type": "string",
        "description": "Código de incidencia en PagerDuty o Jira"
      }
    },
    "required": ["target_migration_version", "justification"]
  },
  "invocationMethod": {
    "type": "GITHUB",
    "org": "enterprise-corp",
    "repo": "database-migration-ops",
    "workflow": "execute-rollback.yml",
    "workflowInputs": {
      "database_identifier": "{{ entity.identifier }}",
      "target_version": "{{ inputs.target_migration_version }}",
      "initiated_by": "{{ user.email }}",
      "justification": "{{ inputs.justification }}"
    }
  }
}

port:
  clientId: os.environ.get("PORT_CLIENT_ID")
  clientSecret: os.environ.get("PORT_CLIENT_SECRET")
  baseUrl: "https://api.getport.io"

clusterName: "production-us-east-1-eks"

resources:
  - kind: apps/v1/deployments
    selector:
      query: '.metadata.namespace != "kube-system"'
    port:
      entity:
        mappings:
          identifier: '.metadata.name + "-" + .metadata.namespace'
          title: '.metadata.name'
          blueprint: '"k8s_deployment"'
          properties:
            namespace: '.metadata.namespace'
            replicas: '.spec.replicas'
            availableReplicas: '.status.availableReplicas // 0'
            image: '.spec.template.spec.containers[0].image'
          relations:
            microservice: '.metadata.labels["app.kubernetes.io/name"]'

Perfil de Seguridad de Backstage y Riesgos Operativos Inherentes

• Soberanía Absoluta de Datos: Ningún metadato ni especificación de servicio sale del perímetro de red de la empresa. No existe ningún proveedor SaaS externo que deba ser homologado como subencargado del tratamiento de datos.
• Compatibilidad con Redes Air-Gapped: Puede operar en redes totalmente aisladas de Internet, empleando réplicas internas de Git y registros privados de paquetes npm (Verdaccio, Artifactory).
• Carga Total de Parcheo: El equipo interno asume la responsabilidad íntegra de mitigar vulnerabilidades en el runtime de Node.js, rotar credenciales de bases de datos, securizar controladores Ingress y gestionar reglas WAF.
• Riesgo de Tokens con Privilegios Amplios: Para escanear repositorios, los pods de Backstage suelen almacenar tokens personales de GitHub (PATs) o credenciales de GitHub Apps con permisos globales de lectura. Si un atacante compromete el pod de Backstage explotando una vulnerabilidad en una dependencia npm, hereda acceso a todos los repositorios corporativos.

Mecanismos de Zero Code Access y Cumplimiento Normativo en Port

• Transmisión Exclusiva de Metadatos: Los agentes de Port solo extraen información estructural y operacional (nombres de servicios, etiquetas de imágenes Docker, recuento de réplicas de pods, severidad de vulnerabilidades). Port jamás clona, parsea ni almacena archivos de código fuente ni registros de bases de datos.
• Conexiones Salientes Cifradas en TLS 1.3: Los exportadores dentro de Kubernetes establecen únicamente conexiones salientes por HTTPS hacia el API de Port. No es necesario abrir puertos de entrada en cortafuegos ni exponer endpoints internos.
• Sin Almacenamiento de Secretos de Ejecución: Al desencadenar acciones de autoservicio, Port no custodia claves IAM ni credenciales de Kubernetes. Emite un webhook hacia el orquestador del cliente (GitHub Actions, Argo), que ejecuta las tareas utilizando los roles IAM nativos del propio cliente.
• Certificaciones de Cumplimiento Empresarial: Port está acreditado con SOC 2 Type II e ISO 27001, cumple plenamente con el RGPD europeo y soporta Single Sign-On empresarial (Okta, Entra ID) junto a aprovisionamiento automatizado mediante SCIM y políticas RBAC granulares.

El Playbook de Migración en 5 Fases: De Backstage a Port

Para aquellas organizaciones que buscan emanciparse del "Impuesto Backstage" y acelerar su madurez en DevEx, este es el plan estructurado de migración en 5 fases:

1. Fase 1: Auditoría del Catálogo y Mapeo de Blueprints (Semana 1): Inventariar todos los tipos de Component, API y Resource existentes en Backstage. Definir los Blueprints correspondientes en Port (Microservicio, Deployment K8s, Base de Datos Cloud) con sus propiedades y relaciones utilizando el proveedor oficial de Terraform de Port.
2. Fase 2: Ingesta de Manifiestos Legacy vía Exportador Git (Semana 2): Desplegar el exportador de GitHub/GitLab de Port configurado para parsear los archivos catalog-info.yaml existentes. Esto puebla el catálogo de Port de forma inmediata sin alterar los repositorios de los desarrolladores.
3. Fase 3: Despliegue de Exportadores en Kubernetes y Cloud en Tiempo Real (Semana 3): Instalar el Helm chart de Port en los clusters de Kubernetes y configurar exportadores cloud para AWS/GCP. Vincular los Deployments en vivo directamente con sus entidades de Microservicio, transicionando el catálogo desde polling estático a streaming de eventos continuo.
4. Fase 4: Traslado de Plantillas de Scaffolder a Acciones de Port (Semana 4): Replicar los formularios template.yaml de Backstage como Port Self-Service Actions. En lugar de procesar scripts en el pod central, configurar las acciones de Port para disparar workflows existentes en GitHub Actions o Argo Workflows, añadiendo aprobaciones vía Slack donde proceda.
5. Fase 5: Activación de Scorecards y Apagado del Monorepo Backstage (Semana 5-6): Establecer scorecards de madurez (Bronce, Plata, Oro). Una vez que los desarrolladores adopten Port como panel principal, apagar los pods de Kubernetes de Backstage, eliminar la base de datos PostgreSQL en RDS, archivar el monorepo TypeScript y reasignar a los ingenieros de plataforma hacia iniciativas críticas de automatización de infraestructura.