Traslade su envío sin perder reputación, historial ni el sueño. Ejecute ambos proveedores en paralelo y después haga la transición por etapas.
Un asistente de IA asigna sus plantillas y webhooks de SendGrid para que los revise
Enumere sus dominios, claves, plantillas, webhooks y supresiones.
Añada los registros DNS de MigoSMTP junto a los antiguos.
Recree plantillas y webhooks e importe las supresiones.
Traslade el tráfico por etapas y vigile la entrega.
Elimine los registros y claves antiguos cuando todo esté estable.
La terminología refleja la documentación del proveedor en el momento de redactar esto. Verifique con la documentación actual antes de publicar.
curl https://api.sendgrid.com/v3/mail/send \
-H "Authorization: Bearer SENDGRID_KEY" \
-H "Content-Type: application/json" \
-d '{ "personalizations": [{ "to": [{ "email": "user@example.com" }] }],
"from": { "email": "hello@yourdomain.com" },
"subject": "Hello",
"content": [{ "type": "text/html", "value": "<p>Hi there</p>" }] }'curl https://api.migosmtp.com/v1/send \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "hello@yourdomain.com",
"to": "user@example.com",
"subject": "Hello",
"html": "<p>Hi there</p>"
}'Solicitudes ilustrativas. Consulte la referencia de la API para ver la lista completa de campos.
Para migrar de SendGrid a MigoSMTP, audite sus claves de API, plantillas dinámicas, webhook de eventos y supresiones, y después añada los registros de autenticación de dominio de MigoSMTP junto a los de SendGrid. Recree las plantillas, dirija su consumidor de webhooks al nuevo formato de payload e importe las supresiones antes de enviar. Dirija primero una pequeña proporción del tráfico por MigoSMTP, vigile la entrega y aumente por etapas. Retire los registros y las claves de SendGrid solo cuando el volumen lleve estable el tiempo que usted decida.
Los equipos migran por motivos como consolidar la infraestructura, querer más control sobre el enrutamiento o cambiar la forma de facturación. Sea cual sea el motivo, gran parte de su configuración se traslada. La Sender Authentication pasa a ser autenticación de dominio, las claves de API se convierten en claves con alcance limitado, los subusuarios pasan a ser espacios de trabajo y las supresiones y los grupos de baja se importan como listas. Los comportamientos específicos de SendGrid, como el versionado de plantillas y el tratamiento de plantillas heredadas, conviene comprobarlos en la documentación vigente del proveedor antes de reconstruir nada. Mantenga por escrito una lista de todo lo que no se asigne uno a uno, para que nadie se lleve sorpresas tras el cambio.
El asistente de migración con IA lee la configuración que usted exporta de SendGrid y propone una asignación: plantillas, variables handlebars, eventos de webhook y estructura de subusuarios, cada uno con una puntuación de confianza. Marca lo que no puede traducir con limpieza en lugar de adivinar. Una persona de su equipo aprueba cada cambio propuesto antes de aplicarlo y cada aprobación se registra, de modo que usted controla qué se traslada y cuándo. Su equipo sigue decidiendo los plazos, el alcance y la reversión, y el asistente nunca envía correo ni edita el DNS por su cuenta.
Empiece por recibos, restablecimientos de contraseña y alertas enviados mediante la API de envío de correo v3. El volumen es predecible, así que puede comparar la entrega con SendGrid antes de migrar nada más.
Mantenga SendGrid activo mientras un pequeño porcentaje del correo pasa por MigoSMTP. Divida por aplicación, plantilla o dominio de destinatario y amplíe la proporción cuando las tasas de rebotes y quejas coincidan.
Si usa subusuarios por cliente o marca, cree un espacio de trabajo de MigoSMTP para cada uno. La reputación, las claves y los datos de supresión permanecen separados como hasta ahora.
Dirija sus manejadores de entrega, rebotes, aperturas y clics a los webhooks de MigoSMTP. Mantenga brevemente una capa de asignación para que los sistemas posteriores que esperan los nombres de evento antiguos sigan funcionando.
Lleve las cuentas principales y los subusuarios a espacios de trabajo de MigoSMTP separados, para que cada equipo conserve sus propias claves e informes.
Migre primero el correo transaccional y después las campañas, para que los mensajes más importantes se asienten antes de que crezca el volumen.
Lee cada plantilla dinámica, convierte las variables handlebars y los bloques condicionales y muestra una vista previa en paralelo. Usted revisa el resultado y aprueba cada plantilla antes de guardarla.
Compara los ajustes del webhook de eventos de SendGrid con los eventos de MigoSMTP y propone una asignación campo por campo con puntuaciones de confianza. No se aplica nada hasta que un miembro del equipo lo autoriza.
Durante la migración por etapas vigila las tendencias de rebotes, diferimientos y quejas frente a su referencia y emite una alerta si se desvían. Usted decide si pausar, mantener o continuar el aumento.
Si pasa a IP dedicadas, redacta un aumento a partir de su historial de volumen y ajusta el plan a medida que llegan los resultados. Usted aprueba cada paso antes de que cambie el calendario de envío.
Usted revisa y aprueba las sugerencias de la IA para su migración desde SendGrid antes de que se aplique nada.
Descargue primero los rebotes, los informes de spam, las bajas y las supresiones por grupo. Importarlos antes del primer envío protege a los destinatarios que ya se dieron de baja y mantiene bajas las tasas de quejas.
Añada los registros DKIM y return-path de MigoSMTP junto a los de SendGrid. Ambos pueden autenticar su dominio a la vez, de modo que puede revertir rápidamente.
Envíe cada plantilla convertida con variables similares a las de producción, incluidos valores vacíos y ausentes. Las diferencias en cómo se evalúan los condicionales son la causa más común de correos rotos.
Migre el correo transaccional y después el de marketing, como pasos separados. Los volúmenes y los patrones de interacción son distintos, así que cada flujo merece su propia comprobación antes de empezar el siguiente.
Cuando todos los servicios usen claves de MigoSMTP, revoque las claves de API de SendGrid. Hágalo en último lugar, cuando los logs ya no muestren tráfico que las use.
Deje activa la cuenta de SendGrid, con el envío detenido, hasta que esté seguro de que nada depende de ella.
¿Migra desde SendGrid? Nuestro equipo puede revisar sus subusuarios y plantillas antes de que empiece.
Audite su configuración de SendGrid, añada los registros de autenticación de dominio de MigoSMTP junto a los existentes, recree plantillas y webhooks, importe las supresiones y traslade el tráfico por etapas. Retire SendGrid solo cuando el volumen sea estable. La mayoría de los equipos usa ambos proveedores en paralelo durante la transición.
Depende de cuántas plantillas, webhooks y aplicaciones de envío tenga. Una sola aplicación con pocas plantillas puede migrarse en días; una configuración con varios subusuarios lleva más tiempo. Calcule varias semanas para la migración por etapas y el calentamiento si añade IP dedicadas.
Hay que reconstruirlas en MigoSMTP, pero no se parte de cero. Exporte el HTML de las plantillas y las variables, y el conversor propone una versión equivalente para que la revise. Compruebe los helpers de handlebars y los condicionales en la vista previa antes de aprobar. Pruebe primero con una pequeña proporción del tráfico y revise los resultados con su equipo.
La reputación pertenece a su dominio y a sus IP de envío, así que no se transfiere automáticamente. Autentique su dominio, envíe primero una pequeña proporción y auméntela gradualmente. En infraestructura compartida se parte de la reputación del pool; las IP dedicadas necesitan calentamiento. Pruebe primero con una pequeña proporción del tráfico y revise los resultados con su equipo.
Expórtela e impórtela en MigoSMTP antes del primer envío, para que las direcciones con rebote y las dadas de baja no vuelvan a recibir correo. Incluya los datos de los grupos de baja si usa grupos. Compruebe el formato de exportación en la documentación vigente del proveedor. Pruebe primero con una pequeña proporción del tráfico y revise los resultados con su equipo.
Si envía por SMTP, normalmente solo cambian el host, el puerto y las credenciales. Si usa la API de envío de correo v3, el cuerpo de la solicitud es distinto, así que actualice la llamada o use un SDK. Pruebe primero en un entorno de staging. Pruebe primero con una pequeña proporción del tráfico y revise los resultados con su equipo.
Sí. Ambos pueden autenticar el mismo dominio a la vez, así que puede dirigir un porcentaje del correo por MigoSMTP y dejar el resto en SendGrid. Divida por aplicación o plantilla para facilitar la comparación. Mantenga activas las credenciales de SendGrid hasta que los logs no muestren más uso.
La IA hace el tedioso trabajo de asignación, no toma las decisiones. Lee su configuración exportada, propone asignaciones de plantillas, webhooks y subusuarios con puntuaciones de confianza y señala las carencias. No se aplica nada hasta que una persona de su equipo aprueba cada cambio.
Sí. La mayoría de los equipos envía primero una pequeña proporción por MigoSMTP y la aumenta gradualmente.
Pasar de un pool compartido a una IP dedicada requiere calentamiento. Use la guía o la calculadora.
Nuestro equipo puede revisar su plan para SendGrid y el calendario del cambio.
Cuéntenos sobre sus dominios, volumen y configuración y le ayudaremos a planificar una transición segura y por etapas.
Crea una cuenta, añade tu dominio y envía tu primer correo.