ricardo/CarneiroTech
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1141594d20
CarneiroTech/Content/Cases/es/asp-to-dotnet-migration.md

10 KiB
Raw Blame History

title slug summary client industry timeline role image tags featured order date seo_title seo_description seo_keywords
Migración ASP 3.0 a .NET Core - Sistema de Rastreo de Cargas asp-to-dotnet-migration Tech Lead en la migración gradual de sistema crítico ASP 3.0 a .NET Core, con sincronización de datos entre versiones y reducción de costos de $20k/año en APIs de mapeo. Empresa de Logística y Rastreo Logística & Seguridad 12 meses (migración completa) Tech Lead & Solution Architect
ASP Classic
.NET Core
SQL Server
Migration
Tech Lead
OSRM
APIs
Arquitectura
true 2 2015-06-01 Migración ASP 3.0 a .NET Core - Case Carneiro Tech Caso de migración gradual de aplicación ASP 3.0 a .NET Core con sincronización de datos y reducción de $20k/año en costos de APIs. ASP migration, .NET Core, legacy modernization, SQL Server, OSRM, tech lead, routing API

Descripción General

Sistema crítico de monitoreo de cargas de alto valor (TVs LED de $600 cada una, cargamentos de hasta 1000 unidades) utilizando rastreo GPS vía satélite. La aplicación cubría todo el ciclo: desde registro y evaluación de conductores (verificación de antecedentes policiales) hasta monitoreo en tiempo real y entrega final.

Desafío principal: Migrar aplicación legacy ASP 3.0 a .NET Core sin downtime, manteniendo operación crítica 24/7.

Desafío

Sistema Legacy Crítico

La empresa operaba un sistema mission-critical en ASP 3.0 (Classic ASP) que no podía detenerse:

Tecnología legacy:

  • ASP 3.0 (tecnología de 1998)
  • SQL Server 2005
  • Cluster failover on-premises (perfectamente capaz de soportar la carga)
  • Integración con rastreadores GPS vía satélite
  • Google Maps API (costo: $20,000/año solo para cálculo de rutas)

Restricciones:

  • Sistema operando 24/7 con cargas de alto valor
  • Imposibilidad de downtime durante migración
  • Múltiples módulos interdependientes
  • Equipo necesitaba continuar desarrollando features durante la migración

Arquitectura de Solución

Fase 1: Preparación de Infraestructura (Meses 1-3)

Upgrade de Base de Datos

SQL Server 2005 → SQL Server 2014
- Backup completo y validación
- Migración de stored procedures
- Optimización de índices
- Pruebas de performance

Estrategia de Sincronización Dual-Write

Implementé un sistema de sincronización bidireccional que permitía:

  1. Módulos nuevos (.NET Core) escribían en la base de datos nueva
  2. Trigger automático sincronizaba datos hacia la base de datos legacy
  3. Módulos antiguos (ASP 3.0) continuaban funcionando normalmente
  4. Zero downtime durante toda la migración
// Ejemplo de sincronización implementada
public class DualWriteService
{
    public async Task SaveDriver(Driver driver)
    {
        // Escribe en base de datos nueva (.NET Core)
        await _newDbContext.Drivers.AddAsync(driver);
        await _newDbContext.SaveChangesAsync();

        // Trigger SQL sincroniza automáticamente hacia base de datos legacy
        // Módulos ASP 3.0 continúan funcionando
    }
}

¿Por qué este enfoque?

  • Permitió migración módulo por módulo
  • Equipo podía continuar desarrollando
  • Rollback sencillo si fuera necesario
  • Reducción de riesgo operacional

Fase 2: Migración Gradual de Módulos (Meses 4-12)

Migré los módulos en orden de complejidad creciente:

Orden de migración:

  1. ✅ Registros básicos (conductores, vehículos)
  2. ✅ Evaluación de riesgo (integración con base policial)
  3. ✅ Gestión de cargas y rutas
  4. ✅ Monitoreo GPS en tiempo real
  5. ✅ Alertas y notificaciones
  6. ✅ Reportes y analytics

Stack de la aplicación migrada:

  • .NET Core 1.0 (2015-2016 era el inicio de .NET Core)
  • Entity Framework Core
  • SignalR para monitoreo real-time
  • SQL Server 2014
  • APIs RESTful

Fase 3: Reducción de Costos con OSRM (Ahorro de $20k/año)

Problema: Costo Prohibitivo de Google Maps

La empresa gastaba $20,000/año solo en Google Maps Directions API para cálculo de rutas de camiones.

Solución: OSRM (Open Source Routing Machine)

Implementé una solución basada en OSRM (motor de ruteo open-source):

Arquitectura de la solución:

┌─────────────────┐
│  Frontend       │
│  (Leaflet.js)   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│  API Wrapper    │─────▶│  OSRM Server │
│  (.NET Core)    │      │  (self-hosted)│
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐
│  Google Maps    │
│  (display only) │
└─────────────────┘

Implementación:

  1. Servidor OSRM configurado en servidor propio
  2. API wrapper amigable en .NET Core que:
    • Recibía origen/destino
    • Consultaba OSRM (gratuito)
    • Devolvía todos los puntos de la ruta
    • Formateaba para el frontend
  3. Frontend dibujaba la ruta en Google Maps (solo visualización, sin API de rutas)
[HttpGet("route")]
public async Task<IActionResult> GetRoute(double originLat, double originLng,
                                           double destLat, double destLng)
{
    // Consulta OSRM (gratuito)
    var osrmResponse = await _osrmClient.GetRouteAsync(
        originLat, originLng, destLat, destLng);

    // Retorna puntos formateados para el frontend
    return Ok(new {
        points = osrmResponse.Routes[0].Geometry.Coordinates,
        distance = osrmResponse.Routes[0].Distance,
        duration = osrmResponse.Routes[0].Duration
    });
}

Frontend con Leaflet:

// Dibuja ruta en el mapa (Google Maps solo para tiles)
L.polyline(routePoints, {color: 'red'}).addTo(map);

Intento con OpenStreetMap

Intenté sustituir también Google Maps (tiles) por OpenStreetMap, que funcionó técnicamente, pero:

❌ A los usuarios no les gustó la apariencia ❌ Preferían la interfaz familiar de Google Maps

✅ Decisión: Mantener Google Maps solo para visualización (sin costo de API de rutas)

Resultado: Ahorro de ~$20,000/año manteniendo calidad de las rutas.

Resultados e Impacto

Migración Completa en 12 Meses

✅ 100% de los módulos migrados de ASP 3.0 a .NET Core ✅ Zero downtime durante toda la migración ✅ Equipo productivo durante todo el proceso ✅ Sistema más rápido y escalable

Reducción de Costos

💰 $20,000/año ahorrados con sustitución de Google Maps Directions API 📉 Infraestructura optimizada con SQL Server 2014

Mejoras Técnicas

🚀 Performance: Aplicación .NET Core 3x más rápida que ASP 3.0 🔒 Seguridad: Stack moderno con parches de seguridad activos 🛠️ Mantenibilidad: Código C# moderno vs VBScript legacy 📊 Monitoreo: SignalR para tracking real-time más eficiente

Fase No Ejecutada: Microservicios & Cloud

Planificación Inicial

Participé en el diseño y concepción de la segunda fase (nunca ejecutada):

Arquitectura planificada:

  • Migración a Azure (cloud estaba apenas comenzando en 2015)
  • División en microservicios:
    • Servicio de autenticación
    • Servicio de GPS/tracking
    • Servicio de rutas
    • Servicio de notificaciones
  • Event-driven architecture con message queues

Por qué no fue ejecutada:

Salí de la empresa inmediatamente después de concluir la migración a .NET Core. La segunda fase quedó planificada pero no fue implementada por mí.

Tech Stack

ASP 3.0 VBScript .NET Core 1.0 C# Entity Framework Core SQL Server 2005 SQL Server 2014 OSRM Leaflet.js Google Maps SignalR REST APIs GPS/Satellite Migration Strategy Dual-Write Pattern

Decisiones Clave & Trade-offs

¿Por qué sincronización dual-write?

Alternativas consideradas:

  1. ❌ Big Bang migration (demasiado arriesgado)
  2. ❌ Mantener todo en ASP 3.0 (insostenible)
  3. ✅ Migración gradual con sync (elegido)

Justificación:

  • Sistema crítico no podía detenerse
  • Permitió rollback módulo por módulo
  • Equipo continuó productivo

¿Por qué OSRM en vez de otros?

Alternativas:

  • Google Maps: $20k/año ❌
  • Mapbox: Licencia paga ❌
  • GraphHopper: Configuración compleja ❌
  • OSRM: Open-source, rápido, configurable ✅

¿Por qué no OpenStreetMap para tiles?

Decisión basada en UX:

  • Técnicamente funcionó perfectamente
  • Usuarios preferían interfaz familiar de Google
  • Compromiso: Google Maps para visualización (gratis) + OSRM para rutas (gratis)

Lecciones Aprendidas

1. Migración Gradual > Big Bang

Migrar módulo por módulo con sincronización permitió:

  • Aprendizaje continuo
  • Ajustes de ruta durante el proceso
  • Confianza del equipo y stakeholders

2. Open Source Puede Ahorrar Mucho

OSRM ahorró $20k/año sin pérdida de calidad. Pero requiere:

  • Expertise para configurar
  • Infraestructura propia
  • Mantenimiento continuo

3. UX > Tecnología A Veces

OpenStreetMap era técnicamente superior (gratuito), pero usuarios prefirieron Google Maps. Lección: Escuchar a los usuarios finales.

4. Planifique Cloud, pero Valide el ROI

En 2015, cloud estaba comenzando. La infraestructura on-premises (cluster SQL Server) era perfectamente capaz. No fuerce cloud si no hay beneficio claro.

Contexto: Por qué 2015 fue un Momento Especial

Estado de la tecnología en 2015:

  • ☁️ Cloud en pañales: AWS existía, Azure creciendo, pero adopción corporativa aún baja
  • 🆕 .NET Core 1.0 lanzado en junio/2016 (usamos RC durante proyecto)
  • 📱 Microservicios: Concepto nuevo, Docker en adopción inicial
  • 🗺️ Google Maps dominante: APIs pagas, pocas alternativas open-source maduras

Desafíos de la época:

  • Herramientas de migración ASP→.NET inexistentes
  • Documentación .NET Core escasa (versión 1.0!)
  • Patrones de arquitectura aún consolidándose

Este proyecto fue pionero al adoptar .NET Core al inicio, cuando la mayoría migraba a .NET Framework 4.x.

Resultado: Migración exitosa de sistema crítico 24/7, ahorro de $20k/año, y base sólida para evolución futura.

¿Quiere discutir una migración similar? Póngase en contacto