Ctrlk
datadike.commdm.datadike.comGithub
linkedin
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Migração de outros MDMs

Guia para trazer clientes de outras plataformas de MDM (Intune, Workspace ONE, SOTI, Hexnode, Scalefusion, MobileIron, Miradore) para o DataDike RMM.

Verdade inconveniente: o Google Android não suporta migração in-place entre MDMs. Cada dispositivo precisa ser re-enrollado — sair do DPC antigo, factory reset, entrar no novo DPC. Isso é uma decisão do Google (o "device owner" é atributo imutável do slot de provisionamento no first-boot).

Não existe MDM no mercado que consiga migrar sem factory reset. Se algum vendor promete, está mentindo ou está falando de Device Admin legado (que tem outros problemas — veja enrollment).

Escopo desta migração

O que MIGRA sem esforço:

  • Cadastro de usuários / permissões (novo no DataDike)

  • Departamentos, tags, políticas nomeadas (recriados no DataDike)

  • Configuração de Google Enterprise (uma nova, do tenant DataDike)

  • Managed Google Play catalog (novo, do tenant Google novo)

O que NÃO migra (por design do Google):

  • O provisionamento dos dispositivos em si — precisa factory reset + re-enroll

  • Histórico de eventos / logs de auditoria do MDM anterior

  • Perfis de configuração já aplicados (precisam ser rewritten como policies AMAPI)

Cenários por origem

De Microsoft Intune

  • Intune usa Android Device Policy oficial do Google como DPC (mesmo DPC que o DataDike RMM usa) — a boa notícia é que o dispositivo já está no ecosistema Android Enterprise correto

  • Ainda assim, factory reset é obrigatório — o DPC verifica o enterpriseId do provisionamento, que é imutável

  • Passos:

    1. No Intune: Retire o dispositivo (Intune → Devices → All devices → selecionar → Retire). Isso remove o work profile ou faz factory reset (depende do modo).

    2. Aguarde o Intune remover o device do inventário (~1-2 min)

    3. No dispositivo: se foi Retire de BYOD, o work profile foi removido — reinstale via nosso fluxo BYOD. Se foi Fully Managed, foi factory-reset — reenrolle via QR code do DataDike.

    4. Aplicar policy DataDike equivalente à do Intune (ver mapeamento abaixo)

De VMware Workspace ONE UEM

  • Workspace ONE tem DPC próprio (Hub). Precisa remover + factory reset.

  • Passos:

    1. Workspace ONE Console → Devices → selecionar → Enterprise Wipe (remove só profile em BYOD, factory reset em Fully Managed)

    2. Aguarde propagação

    3. Reenrolle no DataDike RMM via QR

  • Atenção: Workspace ONE tem features específicas (Windows enrollment, Apple ADE) que não migram para o DataDike (que é Android-only). Se o cliente usa iOS ou Windows, o DataDike não substitui — precisa ferramenta complementar.

De SOTI MobiControl

  • SOTI tem DPC próprio + agent Android

  • SOTI Console → Devices → selecionar → Wipe (opção "Enterprise Wipe" para BYOD, "Full Wipe" para DO)

  • Reenrolle no DataDike

  • Feature-parity: SOTI tem muitas capabilities via SOTI Surf / SOTI Assist que não têm equivalente no DataDike. Documente o gap com o cliente antes de fechar.

De Hexnode / Scalefusion / MobileIron / Miradore

Fluxo similar: Retire/Unenroll no console antigo → factory reset (se DO) → reenroll no DataDike via QR.

Mapeamento de policies

O DataDike usa AMAPI. Se o MDM origem também usava AMAPI (Intune, Workspace ONE moderno), o mapeamento de campos é 1:1 porque estamos no mesmo schema Google.

Se o MDM origem usava Device Admin legado ou APIs proprietárias, o mapeamento não é direto — precisa ser recriado.

Conceito no MDM origem
Equivalente DataDike

Password profile / Compliance profile

Policy → passwordPolicies[]

App installation policy

Policy → applications[].installType: FORCE_INSTALLED

App configuration

Policy → applications[].managedConfiguration

Wi-Fi profile

Policy → openNetworkConfiguration (ONC)

VPN configuration

Policy → alwaysOnVpnPackage

Kiosk / Single-app mode

Policy → kioskCustomLauncherEnabled ou installType: KIOSK

Restrictions (camera / USB / screenshot)

Policy → cameraAccess, usbDataAccess, screenCaptureDisabled

Compliance rules

Policy → policyEnforcementRules[]

Groups / Smart Groups

DataDike → Departments + Tags

Managed Google Play apps

Mesmo — mas o Google Enterprise binding é diferente. Você recria o catálogo no tenant novo.

Estratégia recomendada — piloto em ondas

Não migre 500 dispositivos de uma vez.

Onda
Escopo
Ação

0 — Preparação

Não-dispositivos

  • Cadastrar admins no DataDike

  • Ligar Google Enterprise do tenant DataDike

  • Recriar policies principais (usar templates como partida)

  • Cadastrar departmentos / tags equivalentes

1 — Piloto

5-10 devices

  • Selecionar devices de baixo impacto (equipe interna de TI)

  • Retire no MDM antigo → factory reset → QR enrollment no DataDike

  • Validar policies aplicando corretamente (appliedState = ACTIVE)

  • Rodar 1 semana para pegar edge cases

2 — Departamento pequeno

20-50 devices

  • Uma unidade de negócio com apoio local (não crítica)

  • Comunicação aos usuários: agendar janela + backup pessoal (se BYOD)

  • Aplicar em massa via zero-touch (se comprou aparelhos novos) ou QR em batch

3 — Rollout

Restante da frota

  • Migração departamento por departamento com janelas de manutenção

  • Manter MDM antigo funcional em paralelo (não desligue até 100% migrado + estabilizado por 1-2 semanas)

4 — Desligamento

Ambiente antigo

  • Desligar assinatura do MDM antigo

  • Arquivar exports de audit trail do MDM antigo por período de retenção regulatório

Cuidados especiais

BYOD — dados pessoais do usuário

Em migrations de BYOD, o Enterprise Wipe / Retire no MDM antigo apaga apenas o work profile. Dados pessoais ficam. Comunique isso claramente aos usuários — muitos entram em pânico achando que vão perder as fotos.

Fully Managed — factory reset perde tudo

Isso é o principal ponto de fricção. Estratégias para reduzir dor:

  • Antes do reset: exportar dados críticos (contatos podem ser sincronizados via conta Google; apps corporativos manterão dados no cloud deles)

  • Após reset: Re-enrollment + policy → apps voltam automaticamente via FORCE_INSTALLED

  • Dispositivos novos: melhor estratégia — comprar hardware novo via Zero-touch (KME) para departamentos migrando, deixar o hardware antigo para ser trocado gradualmente

Cada tenant Google Enterprise tem seu próprio catálogo Managed Google Play. Ao migrar:

  1. Public apps (Play Store) — apenas selecionar no novo tenant. Zero esforço.

  2. Private apps (APKs próprios do cliente) — precisa republicar no novo tenant. Google não migra automaticamente entre organizações.

  3. Managed Configurations (schemas JSON custom por app) — recriar no novo tenant.

Timeline realista

Frota de 100 devices:

  • Preparação: 1 semana (admins, policies, catálogo)

  • Piloto: 1-2 semanas

  • Rollout: 2-4 semanas dependendo de logística de factory reset

  • Desligamento: 1-2 semanas após rollout completo

  • Total: 5-9 semanas

Frota de 1000+ devices: 3-6 meses.

Suporte durante a migração

O time DataDike acompanha migrations com:

  • Workshop de kickoff (1h) — mapeamento das policies do MDM origem para AMAPI

  • Sessão de piloto (2h) — assistir provisionamento dos primeiros 5 devices

  • Escala 24x5 durante rollout massivo

Fale com seu account manager para detalhes.

AnteriorAlertas e RelatóriosPróximoPerguntas frequentes

Atualizado

Isto foi útil?