> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/product-guide/configuracoes/rmm/migracao-de-outros-mdm.md).

# 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**.

{% hint style="danger" %}
**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](/product-docs/product-guide/configuracoes/rmm/enrollment.md)).
{% endhint %}

## 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  | <ul><li>Cadastrar admins no DataDike</li><li>Ligar Google Enterprise do tenant DataDike</li><li>Recriar policies principais (usar templates como partida)</li><li>Cadastrar departmentos / tags equivalentes</li></ul>                                                                  |
| 1 — Piloto               | 5-10 devices      | <ul><li>Selecionar devices de baixo impacto (equipe interna de TI)</li><li>Retire no MDM antigo → factory reset → QR enrollment no DataDike</li><li>Validar policies aplicando corretamente (<code>appliedState = ACTIVE</code>)</li><li>Rodar 1 semana para pegar edge cases</li></ul> |
| 2 — Departamento pequeno | 20-50 devices     | <ul><li>Uma unidade de negócio com apoio local (não crítica)</li><li>Comunicação aos usuários: agendar janela + backup pessoal (se BYOD)</li><li>Aplicar em massa via zero-touch (se comprou aparelhos novos) ou QR em batch</li></ul>                                                  |
| 3 — Rollout              | Restante da frota | <ul><li>Migração departamento por departamento com janelas de manutenção</li><li>Manter MDM antigo funcional em paralelo (não desligue até 100% migrado + estabilizado por 1-2 semanas)</li></ul>                                                                                       |
| 4 — Desligamento         | Ambiente antigo   | <ul><li>Desligar assinatura do MDM antigo</li><li>Arquivar exports de audit trail do MDM antigo por período de retenção regulatório</li></ul>                                                                                                                                           |

## 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

### Managed Google Play — recriar o catálogo

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.