Un servidor dedicado no gana por su nombre, y un VPS no es suficiente solo porque admite conexiones remotas. La compra correcta es la que sostiene tus tareas reales, con las licencias necesarias, un alcance de soporte claro y un costo total que puedes asumir. Dos ofertas con la misma cantidad de memoria pueden dar resultados distintos; dos ofertas de categorías diferentes pueden resolver igual de bien una carga concreta.

Esta guía sirve para comparar propuestas para escritorios o aplicaciones remotas. No establece una cantidad universal de usuarios por servidor. Su resultado es una ficha de compra y un piloto con condiciones de aceptación, no una promesa de rendimiento basada en una etiqueta.

Ve directo a: qué estás comprando · matriz de ofertas · piloto comparable · costo total · decisión documentada.

1. Separa la máquina, las sesiones y el servicio

En una propuesta de servidor dedicado, pregunta qué hardware físico queda asignado exclusivamente al cliente y qué componentes siguen dependiendo de una infraestructura común. Un equipo exclusivo puede usar almacenamiento externo, conectividad compartida o servicios de administración de terceros. No des por incluido un enlace exclusivo ni una segunda máquina para sustituirlo.

En una propuesta VPS, solicita la política concreta de CPU, memoria y almacenamiento. El número de vCPU no explica por sí solo su disponibilidad sostenida ni la generación del procesador. Tampoco equivale automáticamente a núcleos físicos reservados. Pide distinguir recursos asignados, límites, ráfagas y cualquier condición de contención. Si la respuesta no consta en la oferta, anótala como pendiente, no como beneficio implícito.

Después identifica el modelo de trabajo: sesiones sobre Windows Server, escritorios virtuales individuales o aplicaciones publicadas. Microsoft distingue estos modelos en su descripción de Remote Desktop Services. Elegir máquina física o virtual no resuelve por sí solo cuál admite tu programa.

Licencias: una línea separada en la cotización

Solicita por escrito el sistema operativo, la modalidad de acceso remoto y las licencias de las aplicaciones. La documentación de licencias RDS explica las CAL por usuario o dispositivo y su compatibilidad de versión. No asumas que cualquier licencia que ya tienes se puede trasladar a cualquier alojamiento: el contrato y el esquema del proveedor importan. Pide al proveedor y al responsable de licenciamiento validar el caso concreto. Microsoft también distingue CAL y SAL por usuario en servicios de proveedores. El programa SPLA contempla derechos no perpetuos para prestar servicios. No presupongas que todas las ofertas usan el mismo esquema ni que una licencia comprada equivale a ese servicio.

No presupuestes un servicio multiusuario usando como sustituto las conexiones reservadas a administración. Incluye también ofimática, base de datos, componentes de terceros y, si corresponde, GPU y derechos de virtualización. Una oferta que omite estas partidas todavía no es comparable con otra que las detalla.

2. Matriz para poner dos ofertas en igualdad de condiciones

Copia la siguiente matriz en tu evaluación. En cada celda escribe el dato, la condición y dónde está documentado. “Incluido” sin alcance, “ilimitado” sin política o “hasta” sin valor sostenido no cierran la comparación. Usa la misma carga y el mismo período de contratación para ambas opciones.

La memoria y el almacenamiento no deben evaluarse aislados del resto de la configuración. Como ejemplo documentado, Microsoft explica que en Azure pueden coexistir límites de rendimiento del disco y de la máquina virtual. Es una ilustración de por qué pedir ambos datos, no una descripción de prestaciones de cualquier VPS ni de una oferta de Cobalt Blue Web.

3. Un piloto que compare trabajo, no sesiones vacías

Antes de probar, acuerda qué acciones representan un día normal y cuáles representan un pico. Una sesión conectada sin aplicaciones abiertas no equivale a una persona registrando operaciones, imprimiendo o generando reportes. La guía de dimensionamiento de Microsoft presenta sus valores como estimaciones iniciales y recomienda validar la carga, incluyendo los inicios de sesión simultáneos. No conviertas una tabla orientativa en una garantía de usuarios para tu sistema.

1. Define el recorrido. Iniciar sesión, abrir el programa, buscar un registro, capturar una operación de prueba, producir un reporte y cerrar correctamente. Añade impresión o periféricos solo si forman parte del trabajo.
2. Congela las condiciones. Misma versión de la aplicación, mismo conjunto de datos de prueba, mismas tareas y mismos equipos de origen. Registra diferencias inevitables entre ofertas.
3. Sube la concurrencia por etapas. Prueba primero el flujo funcional y después grupos de sesiones activas. No empieces con una carga máxima contra producción.
4. Incluye un arranque de jornada. Compara perfiles existentes y nuevos si ambos ocurren en la empresa. El tiempo de entrada merece su propia medición.
5. Repite las tareas. Guarda los tiempos individuales, la mediana, el peor resultado observado y los errores. No mezcles ejecuciones diferentes para fabricar un promedio favorable.
6. Correlaciona con recursos. Un responsable técnico debe observar CPU, memoria, paginación, almacenamiento y red durante el mismo intervalo. El síntoma del usuario y el contador deben tener la misma referencia temporal.

La guía de rendimiento de hosts de sesión subraya la importancia de las aplicaciones y sus patrones de uso. Si aparece un problema, no desactives protecciones para hacer que la prueba “pase”. Documenta la causa y ensaya únicamente cambios revisados y autorizados en el entorno de prueba.

Abre la ficha de comparación del piloto

• Oferta y configuración exacta: ____
• Versión de la aplicación y datos de prueba: ____
• Sesiones activas y tareas concurrentes: ____
• Origen de conexión y horario: ____
• Tiempo de inicio de sesión, cinco observaciones: ____
• Tiempo de tarea crítica, cinco observaciones: ____
• Mediana / peor observado / errores: ____
• Recursos observados durante la tarea: ____
• Criterio de aceptación acordado antes de probar: ____
• Resultado, limitaciones y responsable de revisión: ____

Si una condición cambia entre pruebas, consérvala como diferencia explícita. No presentes esa comparación como un ensayo controlado.

Ejemplo hipotético: por qué la etiqueta no decide

Una empresa evalúa una oferta A virtual y una B física para la misma tarea de cierre. En el ensayo ilustrativo, los cinco tiempos de A son 18, 20, 19, 21 y 22 segundos; los de B son 16, 17, 35, 18 y 34. La mediana de A es 20 segundos y su peor observado 22; en B son 18 y 35. B tiene mejor mediana, pero mayor variación en esta muestra.

Esos diez datos no demuestran que los VPS sean más estables ni que los dedicados fallen. Obligan a investigar las ejecuciones lentas, repetir el ensayo y revisar si coinciden con almacenamiento, otro proceso o una diferencia de configuración. Si el negocio había acordado que esa tarea no superara 25 segundos en el piloto, B todavía no cumple ese criterio. El umbral es de este ejemplo, no una recomendación universal.

4. Calcula el costo del servicio completo

Compara el mismo período y moneda, con impuestos tratados de la misma forma. Separa el pago recurrente de los costos de entrada y salida. La tarifa base puede ser menor y el costo de operación mayor si el equipo interno termina resolviendo perfiles, actualizaciones e incidentes que otra propuesta sí atiende.

Abre la hoja de costo total para doce meses

Total comparable = 12 × costo mensual completo + transición inicial + gastos extraordinarios previstos.

• Mensual: infraestructura + licencias + administración + protección de datos contratada + cargos recurrentes de uso.
• Transición: preparación, validación, traslado y capacitación que realmente estén presupuestados.
• Extraordinarios: ampliaciones previstas, asistencia fuera de alcance y salida si se evaluará dentro del período.
• Tiempo interno: horas estimadas × costo interno por hora, mostrado aparte como estimación.

Evita contar dos veces una partida incluida en el paquete. No asignes ahorros ni costo de incidentes sin una base documentada. Si hay permanencia, anticipos o cargos variables, escribe sus condiciones junto al total.

Un socio experimentado puede justificar una tarifa mayor por el trabajo que asume y por reducir tiempo de diagnóstico y coordinación. La evidencia debe ser su alcance, responsables y forma de atender problemas, no una promesa de que nunca habrá interrupciones. Pregunta lo mismo a Cobalt Blue Web y a cualquier otro proveedor.

5. Decide con condiciones, no con una regla de usuarios

Una máquina dedicada única sigue siendo un punto de fallo si el diseño no ofrece otra vía de servicio. Una máquina virtual tampoco hereda continuidad automática por estar en la nube. Ampliar o migrar puede requerir reinicio, coordinación o una ventana: exige el procedimiento concreto antes de convertirlo en compromiso con tus usuarios.

Cómo usar IA sin delegarle la decisión técnica

Puede ayudar a transformar cotizaciones anonimizadas en la matriz y señalar campos ausentes. Dale la instrucción de escribir “no especificado” cuando falte evidencia y de conservar el enlace o la sección de cada dato. Una persona debe verificar los resultados contra la propuesta original. No cargues credenciales, contratos confidenciales o datos de empleados en herramientas no aprobadas, ni aceptes un número de usuarios inventado por el modelo.

Continúa por el problema específico

Si el piloto revela diferencias por ubicación, revisa el diagnóstico de latencia para oficinas remotas. Si el obstáculo es una aplicación heredada, usa la guía de compatibilidad y pruebas para Visual Basic. La selección de infraestructura viene después de entender esas condiciones, no en lugar de hacerlo.

La mejor propuesta es la que puedes explicar con evidencia: qué ejecutará, bajo qué carga, quién lo mantendrá, qué cuesta realmente y qué ocurrirá cuando necesites cambiarla.