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

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.datadike.com/product-guide/configuracoes/rmm/migracao-de-outros-mdm.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.