Amplía un servidor antiguo cuando una actualización concreta resuelva un cuello de botella medido; migra cuando la antigüedad de la plataforma convierta cada componente añadido en otra dependencia.
La comparación útil no es entre el coste de la actualización y el precio de un chasis nuevo. Es el coste de los próximos tres años en electricidad, interfaces, soporte de firmware, piezas de repuesto, tiempo de recuperación, traslado de datos y la probabilidad de que aparezca inmediatamente otro cuello de botella tras la primera actualización.
Identifica el cuello de botella que motivó la decisión
Mide la saturación de la CPU, la presión sobre la memoria, la capacidad del pool, el rendimiento de la red, la disponibilidad de PCIe, el consumo eléctrico, las temperaturas y la duración de las copias de seguridad. Identifica el único cuello de botella que impide ejecutar la siguiente carga de trabajo.
Un enfoque práctico para planificar el hardware del homelab parte de las cargas de trabajo y de las funciones de la plataforma, en lugar de comprar capacidad por adelantado.
La ampliación es razonable cuando un único componente reemplazable resuelve el límite medido. Si la CPU, el límite de memoria, los puertos de almacenamiento y la velocidad de red son insuficientes, el problema afecta a toda la plataforma.
Comprueba qué componentes de la plataforma siguen teniendo soporte
Registra la antigüedad de la placa base, la disponibilidad de firmware, la memoria compatible, el comportamiento de arranque, el modo del controlador de almacenamiento, la disponibilidad de fuentes de alimentación y ventiladores de repuesto, y si se pueden instalar tarjetas de red modernas o HBA sin conflictos de líneas PCIe.
El hardware empresarial antiguo puede ser fácil de mantener, pero tener un consumo en reposo elevado y piezas propietarias. El hardware de consumo antiguo puede ser eficiente, pero carecer de gestión remota y de repuestos fáciles de conseguir.
Migra cuando un fallo de la placa base o del controlador obligaría a buscar en el mercado de segunda mano antes de poder iniciar la recuperación. Amplía solo cuando ya tengas repuestos críticos y registros de configuración.
Compara el coste total durante los próximos tres años
Suma el coste de la electricidad, las tarjetas adaptadoras, los ventiladores de repuesto, las bandejas para unidades, la capacidad del SAI y el tiempo necesario para migrar. Una actualización barata no lo es si obliga al sistema a mantener un alto consumo en reposo o a usar un controlador sin soporte.
La migración puede compensar gracias a un menor consumo eléctrico y a la necesidad de menos adaptadores, pero solo si el nuevo sistema se dimensiona para cargas de trabajo reales en lugar de una ampliación especulativa.
| Aspecto de la decisión | Ampliar el servidor actual | Migrar a una plataforma nueva |
|---|---|---|
| Trabajo inicial | Bajo si solo se hace una actualización | Mayor esfuerzo de montaje y transferencia |
| Consumo en reposo | Normalmente no cambia o aumenta | Puede reducirse considerablemente |
| Riesgo de fallo | Conserva los componentes principales antiguos | Introduce riesgo de migración |
| Compatibilidad | Limitada por la plataforma antigua | Interfaces y soporte nuevos |
| Reversión | Sencillo si la actualización es reversible | Requiere conservar temporalmente el servidor antiguo |
Compara las opciones de recuperación antes que el rendimiento
Para ampliar, simula el fallo de la pieza irremplazable más antigua. ¿Se puede importar el almacenamiento en otro equipo? ¿Se guardan fuera del servidor las entradas de arranque, las claves de cifrado y las definiciones de los servicios?
Para migrar, prepara primero un servicio y un subconjunto de datos. Un caso documentado de migración de un homelab ilustra por qué las actualizaciones, los cortes de suministro y los cambios de almacenamiento deben tratarse como una sola transición controlada, en vez de como compras aisladas.
Prefiere la opción con una reversión probada. Un servidor nuevo más rápido no es más seguro hasta que funcionen la restauración, los permisos, el DNS y el acceso de los clientes.
Sigue la regla de una sola actualización
Amplía cuando una sola actualización elimine el cuello de botella, haya repuestos conocidos para la plataforma principal, el consumo en reposo siga siendo aceptable y la recuperación se ajuste al objetivo. Fija una fecha de revisión en lugar de permitir actualizaciones incrementales permanentes.
Migra cuando deban cambiar dos o más límites de la plataforma, el equipo antiguo no tenga una vía de sustitución o los costes anuales de electricidad y adaptadores se acerquen al valor del nuevo sistema. Usa la guía de selección de sistemas operativos para servidores domésticos para definir deliberadamente el nuevo modelo de recuperación.
Deja de ampliar si la actualización cambia a la vez la topología de almacenamiento, la fuente de alimentación, la refrigeración y el sistema operativo. En ese punto ya estás migrando, pero sin un plan claro para volver atrás.
Comparaciones de productos
Más para leer

Ripple-65B frente a Qwen3.8-27B para programar en local: ¿cuál se adapta a tu equipo?
Compara las opciones de hardware local y entornos de ejecución para Ripple-65B Preview y Qwen3.8-27B, con un plan de pruebas controlado para cargas de...

LFM2.5-24B-A2B vs DeepSeek API: ¿Cuál se adapta mejor al flujo de trabajo de tu agente en el servidor doméstico?
Compara la inferencia local de LFM2.5-24B-A2B con la API de DeepSeek para agentes de servidores domésticos: límites de privacidad, hardware, mantenimiento, calidad y costos.

Granite Speech 5.0 frente a la transcripción en la nube: comparación de privacidad, hardware y precisión
Compara Granite Speech 5.0 local con la transcripción en la nube en cuanto a privacidad del audio, configuración, hardware, precisión, mantenimiento y flujos de...



