KiwiCloud Migration PlaybookKiwiCloud 迁移手册

This revision history covers all documents in this set — the Migration Playbook and its Appendixes. Entries for Appendix revisions will be added here as they are released.

This Migration Playbook is a working document prepared by the KiwiCloud team to guide customers through the transition from iMinKit’s device management module to the KiwiCloud UEM platform. It is intended to serve as a practical reference for both the KiwiCloud team and the customer throughout the migration journey.

In this document, the term “Migration” refers to the system transition and data synchronization from iMinKit to the KiwiCloud UEM platform, including device data, grouping configurations, legacy policies, and account structures (including the iMinKit Official Account and all associated iMinKit Sub-accounts). During this process, data and configurations are converted into KiwiCloud platform-structured formats rather than transferred as-is. This migration does not constitute a full retirement of the iMinKit platform. iMinKit will continue to operate for basic account and device ownership operations beyond 2026.

This Playbook references several account types — including the iMinKit Official Account, iMinKit Sub-account, KiwiCloud Trial Account, KiwiCloud Migrated Account, and KiwiCloud Bridging Account. For complete definitions, cross-connections, and additional account types, refer to the separately distributed Appendix 1 – Account Types & Terminology.

This document will be continuously refined as the migration process evolves. Updates may cover the migration approach and process, the project-related document set, and customer-specific details such as migration windows and rollback criteria, all of which will be discussed and agreed with each customer.

iMinKit is iMin Tech’s platform for account management and device ownership, serving as the commercial and logistics layer between iMin Tech and its customers. Its core capabilities include:

• Device ownership — device overview, ownership lookup, transfer, allocation, and gifting (with inbound and outbound transfer history)
• Account management — company profile, partners, operators, support, and ticket records

Through integration with iMin Tech’s ERP system, device serial numbers (SNs) are imported into customer iMinKit accounts based on orders. While iMinKit has included a basic, non-policy-based device management capability, this capability will be retired by December 31, 2026. iMin APP Store management on iMinKit is discontinued from the point of official migration, except for My Apps, which remains available to customers until December 31, 2026, 23:59 and is no longer available from 2027. APP policies currently configured on iMinKit are migrated to the KiwiCloud UEM platform during official migration. iMinKit itself will continue to operate beyond 2026 for account management and device ownership operations.

After migration, iMinKit becomes a limited-access console focused on account management and device ownership (including transfer and allocation), while the KiwiCloud UEM platform delivers the customer’s device management, APP policies, remote assistance, scheduled tasks, notifications, and user authorization capabilities.

KiwiCloud is an independent, policy-driven UEM platform that serves as the successor to iMinKit’s device management functions. As a service provider to iMin Tech, the KiwiCloud platform offers significantly more powerful device and application management capabilities to customers of both iMin Tech and KiwiCloud. Customers pay a per-device, per-year license fee to KiwiCloud based on their selected license tier.

iMinKit and the KiwiCloud platform operate as independent platforms with separate authentication systems. After migration, a shortcut to the KiwiCloud platform appears in the upper-right corner of the enterprise iMinKit page, providing a direct entry point to the KiwiCloud platform login page. Customers log in to the KiwiCloud platform using the same credentials as their iMinKit account. After a successful official migration, the KiwiCloud platform account password can be changed independently by the customer and may differ from the iMinKit password.

To continuously enhance device enrollment, policy delivery, application management, remote assistance, map and geofence services, reporting, and related capabilities, the relevant device management functions currently handled through iMinKit will be gradually migrated to the KiwiCloud platform. The migration is driven by the following business needs:

• End of the IoT Service: iMin Devices connect to iMinKit through an IoT service, and all device configuration and application installation is delivered through this IoT service. However, iMinKit’s IoT service provider, Ali Cloud, has decided to terminate its IoT business and will gradually shut down existing IoT services.
• Platform Modernization: iMinKit’s device management module has reached its functional ceiling and no longer meets the evolving demands of modern enterprise device management. The KiwiCloud platform is purpose-built to address current and future operational needs with scalable, policy-driven architecture.
• Operational Efficiency: iMinKit’s fragmented management approach, where rules for app installation, uninstall prevention, blacklists, and permissions must be configured separately, creates significant administrative overhead. The KiwiCloud platform consolidates these controls into unified policies, reducing repetitive operations and human error.
• Enhanced Security: The KiwiCloud platform introduces advanced encryption technologies including TLS encryption and SigV4 signatures, alongside granular access controls, addressing security gaps present in iMinKit.
• Data Protection and Regional Compliance: The KiwiCloud platform leverages the global infrastructure of AWS Cloud services, with dedicated regional service nodes in Europe (Frankfurt), USA (Virginia), China (Beijing), and Singapore (Singapore City). This architecture ensures data remains within its designated region, supporting data residency requirements and local regulatory compliance. Remote access is also initiated from the corresponding regional service node to further align with jurisdiction-specific regulations.
• Regulatory Compliance for Application Publishing: From 2027 onwards, public application publishing will move to a regulated approval process on the KiwiCloud platform and the Google Play Store, replacing iMinKit’s current model where public apps are exposed to all iMin Devices without a regulatory review procedure. This change is driven by Google regulatory requirements and the need to prevent copyright issues, ensuring ongoing compliance with applicable regulations.
• Kiosk Remote Accessibility: The iMin Tech-developed Remote Assistance application is upgraded to KiwiCloud Remote Assistance as part of the migration process. This enables IT administrators to remotely access and manage devices operating in kiosk mode using the globally recognized AnyDesk remote access solution, significantly improving support responsiveness and reducing on-site intervention requirements.
• Enhanced Log Management: The KiwiCloud platform introduces an enhanced device log system that enables structured troubleshooting and issue resolution across both Tier-1 and Tier-2 technical support functions, providing greater diagnostic visibility and accelerating incident resolution.
• Geolocation-Based Management: The KiwiCloud platform introduces geolocation capabilities, including a devices map for real-time visibility of device locations and geofencing to define geographic boundaries that trigger automated policy actions. These capabilities enable more proactive and location-aware device management, something iMinKit does not support. (Available under KC Enhanced license only.)
• Patch Management and OTA Updates: The KiwiCloud platform includes a dedicated, independent Over-The-Air (OTA) update platform, currently provided free of charge to all customers, enabling centralized management of software patch releases and firmware upgrade policies across the entire device fleet.
• Strategic Product Roadmap: iMin Tech has designated the KiwiCloud platform as its exclusive UEM platform going forward. The retirement of iMinKit’s device management module by December 31, 2026 makes this migration both strategically critical and time-bound.
• Business Continuity: The migration is designed to ensure that end-user device operations continue without interruption. Upon migration completion, iMinKit’s device management module will be retired. However, iMinKit will remain available for basic account and device ownership operations.

The migration covers the synchronization and transition of the following from iMinKit to the KiwiCloud UEM platform:

• The iMinKit Official Account and all associated iMinKit Sub-accounts (full organizational hierarchy), accessible on the KiwiCloud platform using the same email credentials as iMinKit
• All enrolled devices. Devices will automatically appear in the customer’s KiwiCloud Migrated Account upon migration, including new devices imported from iMin Tech’s ERP system in the future
• Configuration data, including device and APP polices, compliance rules, boot animations, secondary screen ads, permission settings, and scanner configurations

Capability Coverage Before and After Migration

The following table summarizes how each customer-facing capability is delivered before and after migration.

iMin APP Store — Availability and Changes from 2027

The upgraded iMin APP Store will remain available on devices after migration, allowing end users to review applications installed on their devices through app policies deployed by the KiwiCloud platform. However, from 2027 onwards, the function allowing end users to download and install public applications published by other customers will no longer be available. This change is driven by Google regulatory requirements and the need to prevent copyright issues. Currently, when a customer publishes a public application to iMin APP Store, the application is exposed to all iMin Devices without a regulatory review procedure.

From 2027, public application publishing will be handled through an approval process on the KiwiCloud platform and the Google Play Store, ensuring compliance with applicable regulations.

Admin Policies Replace End-user Installs

Opening Framing — As part of the migration, iMinKit’s APP management module retires alongside the device management module on December 31, 2026. APP management functions move to the KiwiCloud platform, fundamentally changing how applications reach devices.

Customers who need to migrate

Customers who need to use KiwiCloud for device and application management. iMinKit’s device and application management capabilities will be taken over by KiwiCloud, with significant improvements. Customers who currently manage devices and applications through iMinKit can continue to manage them on KiwiCloud after migration.

Customers who do not need to migrate

Customers who, apart from device ownership management on the iMinKit platform, are not currently using iMinKit to manage devices and applications — for example, customers who already manage GMS-certified devices with a third-party MDM system. If these customers need to use KiwiCloud in the future, we can still migrate them at that time.

Devices that run deeply customized firmware — with all iMin Tech applications, services and SDKs removed (such as the iMin APP Store, the Auto Install service and the Ali Cloud IoT interface) — that is also not GMS-certified (Google Mobile Services removed) could not be managed on iMinKit in the first place. After migration, these devices still cannot be managed on the KiwiCloud platform, so they are not included in the scope of this migration project.

The KiwiCloud platform supports three device management modes. The appropriate mode for each device is determined by the customer’s license tier and device type:

For the purposes of this document, the following license tier naming conventions apply:

• KiwiCloud Essential (hereinafter referred to as iMin Essential)
• KiwiCloud Enhanced (hereinafter referred to as KC Enhanced)

• Synchronization and transition of the iMinKit Official Account and all associated iMinKit Sub-accounts, devices, configurations, and policies from iMinKit to the KiwiCloud platform (excluding all log types). The customer’s organization structures and accounts are synchronized to the KiwiCloud platform automatically by the KiwiCloud platform system, triggered by the KiwiCloud team during the verification and migration phases (see Section 3).
• Device re-enrollment under the appropriate management mode (IMA/KMA/GMA) based on customer’s license tier and device type.
• iMin APP Store and Remote Assistance Upgrade: The legacy iMin APP Store and the iMin Tech-developed Remote Assistance application will be upgraded during the migration process. The KiwiCloud team will create the upgrade policy for the iMin APP Store and Remote Assistance on the iMinKit platform under the customer’s iMinKit Official Account (the team adds the two applications to it manually), assigned to test devices during test migration (Phase 3) and extended to all devices in official migration (Phase 4). Customers retain the ability to review released business applications in My Apps on the iMinKit platform until the module is retired on December 31, 2026, 23:59.

  The upgrade is mandatory and silent: it is delivered to devices automatically through the upgrade policy and requires no action from end users.

  Upon successful upgrade, the iMin Tech-developed Remote Assistance application becomes KiwiCloud Remote Assistance — an updated version of the same application that acts as an agent enabling end users to initiate remote assistance requests. KiwiCloud Remote Assistance is capable of connecting to both the iMinKit original remote assistance service enabled through the third-party Sunlogin services and the KiwiCloud remote assistance service enabled through the third-party AnyDesk services:

  • Before migration is performed: KiwiCloud Remote Assistance connects to the original iMinKit remote assistance service, ensuring remote assistance continuity during the pre-migration period.
  • After successful migration and AnyDesk installation: KiwiCloud Remote Assistance connects to the KiwiCloud remote assistance service, enabling IT administrators to remotely access and manage devices using AnyDesk as the remote access solution.

  This dual-service mechanism ensures that remote assistance remains available to end users throughout the entire migration process without interruption. KiwiCloud Remote Assistance is delivered through the upgraded iMin APP Store on the device.

  After migration, the iMin Tech-developed remote assistance service is no longer provided. Once AnyDesk has been successfully installed, the iMin Tech-developed Remote Assistance application on the device obtains the AnyDesk remote access ID (generated by AnyDesk) and uploads it to KiwiCloud. Using this remote access ID, the customer’s administrators can initiate active remote access requests to the device on KiwiCloud.

  !Notes

  • Customers should ensure that iMin APP Store and Remote Assistance are not blacklisted on the iMinKit platform prior to migration, as blacklisting these applications will prevent the upgrade policy from being applied successfully. Early applicants whose applications are blacklisted can still migrate — see the notes under Phase 2.
  • For iMin Devices running Android OS 14 and above, the iMin Tech-developed Remote Assistance application and iMin APP Store are not pre-installed. The functions of these applications are performed by the KC APP, which serves as the management agent and comes pre-installed on such devices. The upgrade policy described above is therefore applicable to legacy devices running Android OS 13 or below only.
• AnyDesk and AD1 Deployment: After the customer’s device data has been synchronized to the KiwiCloud platform, AnyDesk and its AD1 plugin are installed on devices through the same KiwiCloud app release policy that carries the iMin APP Store and Remote Assistance upgrade — four items in a single policy. The Migration Auto-Task adds AnyDesk and AD1 to this policy automatically as part of the migration process (see Section 3 for details), with the KiwiCloud system receiving policy creation instructions from the iMinKit system through API connection. The KiwiCloud team will verify the AnyDesk policy configuration to ensure it has been correctly applied.
• iMinKit Accounts and Device Ownership Operations Continuity: iMinKit will continue to support device ownership and allocation operations for the customer throughout and beyond the migration.
• Integration setup between the iMinKit platform and the KiwiCloud platform to enable ongoing automatic device synchronization
• Post-migration data validation and business workflow testing
• User onboarding, including guides, tutorials, and technical support

• Custom development, feature modifications, or enhancements to the KiwiCloud platform
• Hardware procurement or physical device replacements
• Android OS Or Firmware Upgrades: Device OS and firmware versions will remain as-is throughout the migration. Any Android OS upgrade initiatives are a separate effort outside this project’s scope.
• iMinKit data not migrated to the KiwiCloud platform: all types of logs (system logs, operation logs, device logs); and authorization configurations on iMinKit (not migrated as menu structures and functionalities differ between the two platforms — to be re-configured by the KiwiCloud Super Admin after migration)
• Migration of data from any third-party MDM/UEM system other than iMinKit
• Devices running deeply customized, non-GMS-certified firmware: devices with all iMin Tech applications, services and SDKs removed (such as the iMin APP Store, the Auto Install service and the Ali Cloud IoT interface) and Google Mobile Services removed could not be managed on iMinKit in the first place and still cannot be managed on the KiwiCloud platform after migration, so they are not included in the scope of this migration project
• Infrastructure setup or cloud provisioning (fully managed by the KiwiCloud team)
• Full iMinKit Platform Shutdown: Only iMinKit’s device management module is being retired by December 31, 2026. iMinKit itself continues to operate for basic account and device ownership operations beyond 2026.

Pre-Project Engagement

This phase occurs before the formal migration project kicks off. It covers all early customer touchpoints and inquiries and is primarily driven by the customer’s own readiness and interest:

• Customer inquires about KiwiCloud migration via email, sales contact, or official channels;
• KiwiCloud team provisions a KiwiCloud Trial Account for the customer for initial exploration of KiwiCloud platform functions; Customer explores KiwiCloud platform functions using the KiwiCloud Trial Account, and may transfer test devices from their iMinKit Official Account to the KiwiCloud Trial Account for initial familiarization; (Optional)
• If a KiwiCloud Trial Account is provisioned, it must be registered with a different email address from the customer’s iMinKit Official Account email. If a KiwiCloud platform account (e.g. KiwiCloud Standalone Account) already exists under the same email as the iMinKit Official Account, the customer must confirm consent to the KiwiCloud team to clear all existing data on that KiwiCloud platform account before migration proceeds.
• Customer reviews Migration Playbook, Appendixes, FAQs and requests clarification on migration process, licensing, or timeline.
• KiwiCloud introduces and shares applicable project-related documents and operational videos (available on the KiwiCloud YouTube channel)

Formal Migration

The formal migration is executed in five phases on a per-customer basis. The KiwiCloud team will run multiple customer migrations in parallel, with standardized processes, checklists, and templates applied consistently across all customers to ensure quality and efficiency.

Migration Process Overview

Migration scheduling is planned by the KiwiCloud team on a per-customer basis, considering factors such as region, device models, and device quantity. It does not operate on a first-come-first-served basis. The KiwiCloud team will reach out proactively to align on a migration schedule and will keep customers informed ahead of any official migration action.

This phase marks the official migration application window for customers, which opens after the pre-project engagement. Its duration will be contingent upon the progress of the Device Compatibility Test (abbr. DCT) being performed by the KiwiCloud team.

Customers will be notified that they may proceed to this phase once the DCT has been completed for all their devices. The duration of this phase will be determined by each customer’s internal IT workflows.

Should customers wish to verify the changes of the two iMin Tech applications, synchronization of data (including device groupings and organizational structures) between iMinKit and KiwiCloud, and the business continuity, they may initiate a test migration on their official iMinKit account using assigned test devices. The length of this phase will be contingent upon each customer’s verification progress.

iMin APP Store and Remote Assistance — Upgrade Verification Criteria

The upgrade is mandatory and silent: it is delivered to devices automatically through the upgrade policy and requires no action from end users.

The upgrade policy is created by the KiwiCloud team on the iMinKit platform and delivered to devices via the iMinKit polling mechanism. The polling mechanism exists only in firmware versions running Android 13 and above. The following criteria should be used by the customer on the device to verify that the upgrade policy has been successfully applied:

!Notes

Official Migration consists of two sequential components with different timeframes:

• iMin APP Store and Remote Assistance upgrade rollout to all devices — may take from a few days to a few months (1–2 months, depending on the number of devices) after the upgrade policy is extended, as devices receive the update progressively via the iMinKit polling mechanism (every 4 hours). The polling mechanism exists only in firmware versions running Android 13 and above. Some devices may not be online immediately, and the upgrade will be delivered when they next come online. If the upgrade progress is too slow, the customer may ask end users to restart their devices before starting business each day.
• Official Migration Auto-Task data synchronization — the Official Migration Auto-Task itself (synchronizing all data and configurations from iMinKit to the KiwiCloud platform) typically completes within a few minutes, depending on data volume.

The upgrade is mandatory and silent: it is delivered to devices automatically through the upgrade policy and requires no action from end users.

Before performing the Official Migration Auto-Task, the KiwiCloud team waits until a meaningful portion of devices (e.g., around 60%, varying per customer) have successfully upgraded to KiwiCloud Remote Assistance. This serves as a smoke test confirming the upgrade policy itself has been correctly deployed — any remaining devices that have not upgraded can then be reasonably attributed to being offline rather than to a policy deployment failure. Once this threshold is reached, the device-level upgrade rollout and the Official Migration Auto-Task data synchronization proceed in parallel; the KiwiCloud team does not wait for 100% of devices to complete the upgrade.

!Notes

The “Device Management → Device List” on the KiwiCloud platform contains only devices that have been enrolled and brought under management. After migration, devices appear as follows:

• IMA devices (Android OS 13 or below) that were activated before migration appear in “Device Management → Device List”.
• IMA devices (Android OS 13 or below) that were not activated before migration appear in “Enrollment → Device Status → To Be Managed → Candidate”.
• IMA devices (Android OS 13 or below) newly activated after migration appear in “Enrollment → Device Status → To Be Managed → Unenrolled”. The customer can enroll such a device through IMA Zero-Touch enrollment; if the device is also GMS-certified, it can alternatively be enrolled through GMA QR Enrollment or GMA Zero-Touch Enrollment.
• Devices running Android OS 14 and above for which no enrollment method that includes the device SN (for example, GMA QR Enrollment or KMA Zero-Touch Enrollment) has been configured on the KiwiCloud platform appear in “Enrollment → Device Status → To Be Managed → Candidate”.
• Devices running Android OS 14 and above for which an enrollment method that includes the device SN (for example, GMA QR Enrollment or KMA Zero-Touch Enrollment) has been configured on the KiwiCloud platform appear in “Enrollment → Device Status → To Be Managed → Unenrolled”.

Unblocking Policy Push (Task 4.5)

After the iMin APP Store upgrade is complete and before the migration is performed, IMA devices record a snapshot of their current configuration and application versions through the upgraded iMin APP Store.

After the account has been migrated, KiwiCloud does not send any policies to devices that remain in the blocked state. This is a protective mechanism: it ensures that the configuration of devices in live operation does not change until the customer is ready.

When policy management needs to be resumed, the customer’s system administrator unblocks the devices on the KiwiCloud platform. Once unblocked, KiwiCloud begins sending the application upgrade policy to these devices in the normal way.

There are two ways to unblock:

• Unblock all — unblock the devices in bulk under the account, so that the whole device fleet returns to regular policy management.
• Unblock partially — unblock only the devices the customer selects. This suits scenarios where the customer wants to verify the migration result on a small scale first — for example, to confirm that new policies are delivered normally before confirming migration for all devices.

Migration Auto-Tasks

Two distinct automated migration functions are used across the migration phases, both executed on the iMinKit platform by the KiwiCloud team:

• Test Migration Auto-Task — executed by the KiwiCloud team during Phase 3 (Test Migration) on the customer’s iMinKit Official Account via the iMinKit platform, covering test devices only. The purpose is to verify platform connectivity, device behavior, and business continuity on a limited scope before committing to full migration. As part of the Test Migration Auto-Task, the KiwiCloud system automatically adds AnyDesk and its AD1 plugin (installation) on the KiwiCloud platform via API connection between the iMinKit system and the KiwiCloud UEM platform, so that the iMin APP Store, Remote Assistance, AnyDesk and AD1 end up together in a single KiwiCloud app release policy. The Test Migration Auto-Task can be rolled back.
• Official Migration Auto-Task — executed by the KiwiCloud team during Phase 4 (Official Migration) on the customer’s iMinKit Official Account via the iMinKit platform, covering all devices. This is the definitive migration action. As part of the Official Migration Auto-Task, the KiwiCloud system automatically adds AnyDesk and its AD1 plugin (installation) on the KiwiCloud platform via API connection between the iMinKit system and the KiwiCloud platform, so that the iMin APP Store, Remote Assistance, AnyDesk and AD1 end up together in a single KiwiCloud app release policy. Prior to performing the Official Migration Auto-Task, the KiwiCloud team will roll back the Test Migration Auto-Task to ensure a clean and conflict-free starting state.

Rollback

The KiwiCloud team executes rollback as a remediation operation when needed (e.g., wide-range business disruption observed post-migration, or incorrect upgrade versions deployed). The rollback may include one or more of the following components, scoped to the specific issue encountered:

• KiwiCloud environment cleanup — deleting all data and configurations from the relevant KiwiCloud environment (the trial environment under the KiwiCloud Trial Account, the test environment created by Test Migration Auto-Task, or the official environment created by Official Migration Auto-Task), depending on which environment requires rollback.
• iMin APP Store and Remote Assistance policy redeployment — deploying corrected upgrade or installation policies on the iMinKit platform if incorrect application versions were deployed to test devices or all devices.
• iMinKit data and configuration restoration — restoring iMinKit’s legacy data or configurations if these were altered by system error or human operation during Test Migration and/or Official Migration.

This phase is intended for customers to monitor device availability and business continuity following the official migration. It is advised not to make any new configuration changes (e.g., device regrouping or policy updates) during this period. The recommended duration for this phase is at least one week.

Project Manager

The Project Manager is the primary point of contact from the KiwiCloud team throughout the migration journey. Responsibilities include coordinating migration scheduling, managing the migration process across all phases, communicating progress and issues to both the KiwiCloud team and the customer, and ensuring the migration is completed successfully and on time.

Product Manager

The Product Manager is responsible for customer-facing product and functional matters throughout the migration. Responsibilities include managing pre-migration customer setup on the KiwiCloud UEM platform, supporting the CSE Team with operational training, clarifying functional issues raised by the customer, and developing training materials to support the migration process.

Technical Manager

The Technical Manager (including R&D team) supports the Project Manager on all technical aspects of the migration. Responsibilities include technical action planning, technology development, device compatibility testing and providing technical assurance throughout the migration phases to ensure a smooth and reliable transition.

Sales Rep.

The Sales Representative is the customer’s first point of contact at KiwiCloud and remains involved throughout the migration journey. Responsibilities include handling pre-migration customer inquiries, clarifying migration policies and licensing options, and supporting the customer with license upgrades where applicable.

Customer Service Engineer (CSE) Team

The CSE Team is the primary technical execution team for the migration. Responsibilities include account operation (creation of eligible type of account), configuring and applying the upgrade policy on the iMinKit platform, executing the automated migration tasks, coordinating account and policy clean-up between platforms, verifying post-migration configurations on the KiwiCloud platform, monitoring upgrade and migration progress, and resolving technical issues arising during or after migration.

Project Coordinator

The Project Coordinator is the primary point of contact from the customer side and the key liaison with the KiwiCloud team. Responsibilities include coordinating internal team members throughout all migration phases, providing migration action instructions and rollback decisions to the KiwiCloud team, and ensuring the customer’s internal stakeholders are aligned and ready at each phase gate.

IT Manager

The IT Manager is responsible for the customer’s technical readiness and hands-on migration activities. Responsibilities include verifying technical readiness based on the prerequisite checklist provided by the KiwiCloud team, providing device information and assigning test devices for the migration, verifying upgrades and platform behavior on test devices, and coordinating with the internal business operation team to observe and report business availability throughout the migration.

• Appendix 1 – Account Types & Terminology
• Appendix 2 – Endpoint Allow-list
• Appendix 3 – Risk Register
• Appendix 4 – iMinKit Platform UI Changes
• Appendix 5 – How to Apply for Migration
• Appendix 6 – Device Model Compatibility
• Appendix 7 – Migration Guidance for SoftPOS Customers
• Appendix 8 – Post-Migration User Guide

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. It defines all account types and terminology frameworks referenced throughout the migration documentation and describes the post-migration authorization model. It is distributed to customers together with the Migration Playbook and related materials.

Overview

This Appendix defines all account types and terminology frameworks referenced in the KiwiCloud Migration documentation. Understanding the distinctions between these account types is important for correctly interpreting the migration process, platform accessibility, and account management actions described throughout the Migration Playbook and related documents.

Account terminology in the context of iMinKit and KiwiCloud migration is organized into three terminology frameworks, each serving a different purpose:

• By Hierarchy (Section 1) – describes the multi-level parent–child relationship between accounts (Main Account / Sub-account).
• By Platform (Section 2) – describes an account’s accessibility to and functionality on the iMinKit and/or KiwiCloud platform.
• By Authorization (Section 3) – describes the roles, access rights, and operational scopes of accounts and users.

The same physical account may be described using different terminologies depending on which framework is being applied; such cross-connections are noted within the relevant account definitions. Section 4 describes the post-migration authorization model.

This terminology framework focuses on explaining the multi-level hierarchical relationship between accounts. Both the iMinKit platform and the KiwiCloud platform support a 5-level account structure. Each platform has its own internal root node — iMin Tech on the iMinKit platform, and KiwiCloud on the KiwiCloud platform — at the top of its hierarchy. These root nodes exist as a technical requirement (every hierarchy must have a root) and are not visible in the customer-facing interface; customers interact with the hierarchy starting from the Main Account level downward.

A Main Account is the email and password used when creating a level-1 organization under the root organization node. A Sub-account is the email and password used when creating a sub-organization under a non-root organization node: level-2 under level-1, level-3 under level-2, and so on until level-5 under level-4.

Every Main Account and Sub-account is, by definition, the Super Admin of the organization it was used to create (see Section 3). User Accounts — accounts that a Super Admin creates and assigns roles to — are not Sub-accounts, and this document no longer describes them as such, to avoid confusion.

These terminologies, Main Account and Sub-account, were widely used in emails, instant messages, and verbal communications before KiwiCloud platform and migration activities were formally introduced to customers and iMin Tech. To avoid ambiguity, it is recommended to prefix such terms with the platform name, as defined below.

1.1. iMinKit Main Account

The email and password used when creating a level-1 organization under the root organization node of the iMinKit platform (iMin Tech). The iMinKit Main Account is the foundational account from which the customer’s iMinKit account hierarchy branches and is the parent of all iMinKit Sub-accounts below it. It is the Super Admin of that level-1 organization and, when created together with the level-1 organization, is always granted Super Admin (Cooperative) authorization by default.

In most contexts the iMinKit Main Account is the same account as the customer’s iMinKit Official Account (see Section 2).

1.2. KiwiCloud Main Account

The email and password used when creating a level-1 organization under the root organization node of the KiwiCloud platform (KiwiCloud). The KiwiCloud Main Account is the foundational account from which the customer’s KiwiCloud account hierarchy branches and is the parent of all KiwiCloud Sub-accounts below it. It is the Super Admin of that level-1 organization. After official migration, a customer’s KiwiCloud Main Account is the same account as their KiwiCloud Migrated Account (see Section 2), inheriting the same email credentials and the same level-1 position previously held by the iMinKit Main Account.

1.3. iMinKit Sub-account

The email and password used when creating a sub-organization (level-2 through level-5) under a non-root organization node on the iMinKit platform. An iMinKit Sub-account is the Super Admin of the sub-organization it was used to create. iMinKit Sub-accounts are typically created for the customer’s partners or sub-organizations and are used primarily for device ownership management operations such as device transfer and allocation between the customer and their partners.

The iMinKit Sub-accounts created together with level-2 through level-5 organization are granted Super Admin (Cooperative) or Super Admin (Controllable) authorization by the Super Admin who holds the iMinKit Main Account.

All iMinKit Sub-accounts are migrated together with the iMinKit Main Account during the Official Migration Auto-Task, ensuring that the entire account structure and organizational hierarchy is fully transitioned from iMinKit to the KiwiCloud platform.

After migration, an iMinKit Sub-account (Cooperative or Controllable sub-type) is automatically synchronized to the KiwiCloud platform as a KiwiCloud Sub-account — the KiwiCloud Super Admin of the corresponding sub-organization. iMinKit User Accounts within the sub-organization are not Sub-accounts; they are also synchronized to the KiwiCloud platform as physical account entities, but without any roles or access permissions — the corresponding KiwiCloud Super Admin must assign roles and access permissions to these accounts on the KiwiCloud platform before they can access it. Refer to Section 4 — Post-Migration Authorization Model for details.

1.4. KiwiCloud Sub-account

The email and password used when creating a sub-organization (level-2 through level-5) under a non-root organization node on the KiwiCloud platform. A KiwiCloud Sub-account is the Super Admin of the sub-organization it was used to create. KiwiCloud Sub-accounts may originate in three ways:

• Migrated from iMinKit at official migration — every iMinKit Sub-account becomes a KiwiCloud Sub-account at the corresponding level after the Official Migration Auto-Task, preserving the customer’s existing organizational hierarchy.
• Created on iMinKit post-migration — after official migration, a newly created iMinKit Sub-account is automatically synchronized to the KiwiCloud platform as a corresponding KiwiCloud Sub-account. The customer’s iMinKit hierarchy and KiwiCloud hierarchy therefore remain continuously synchronized for newly created iMinKit Sub-accounts. Customers are recommended to continue managing organization structure and associated Super Admin accounts on the iMinKit platform after official migration.
• Created directly on the KiwiCloud platform — under a KiwiCloud Main Account, KiwiCloud Trial Account, or KiwiCloud Bridging Account, to support multi-user or multi-organizational structures on the KiwiCloud platform. KiwiCloud Sub-accounts created directly on the KiwiCloud platform are not synchronized back to the iMinKit platform.

This terminology framework focuses on explaining an account’s accessibility to and functionality on the iMinKit and/or KiwiCloud platform. The account types defined in this framework are:

2.1. iMinKit Official Account

The account that the customer currently uses to log in to the iMinKit platform. This account is registered with the customer’s official business email address and is the primary account governing all device ownership, allocation, and management operations on iMinKit. It is accessible to the iMinKit platform only prior to migration.

Upon successful Test Migration Auto-Task (Phase 3) or Official Migration Auto-Task (Phase 4), the iMinKit Official Account becomes a KiwiCloud Migrated Account (see below), accessible to both the iMinKit platform and the KiwiCloud platform using the same email credentials.

2.2. KiwiCloud Migrated Account

The official KiwiCloud account resulting from a successful Test Migration Auto-Task or Official Migration Auto-Task. It is accessible to both the iMinKit platform and the KiwiCloud platform using the same email credentials as the customer’s iMinKit Official Account.

• During Phase 3 (Test Migration): The iMinKit Official Account is temporarily converted into a KiwiCloud Migrated Account via the Test Migration Auto-Task, allowing the customer to log in to the KiwiCloud platform and verify platform connectivity, device behavior, and business continuity on test devices. This is a temporary state — the Test Migration Auto-Task will be rolled back by the KiwiCloud team at the start of Phase 4 before the Official Migration Auto-Task is performed.
• After Phase 4 (Official Migration): The iMinKit Official Account is permanently converted into a KiwiCloud Migrated Account via the Official Migration Auto-Task. This is the definitive and final state. All iMinKit Sub-accounts are migrated at the same time, preserving the full organizational hierarchy on the KiwiCloud platform.

After a successful Official Migration Auto-Task, the KiwiCloud platform account password may be changed independently by the customer and may differ from the iMinKit platform password.

2.3. KiwiCloud Trial Account

An account provisioned by the KiwiCloud team for a customer to allow early exploration of the KiwiCloud platform. The KiwiCloud Trial Account is registered with a different email address from the customer’s iMinKit Official Account (if any), as the provisioning process creates a trial-purpose account on the iMinKit platform under this email and any conflict with an existing iMinKit Official Account would prevent the provisioning from completing successfully.

The KiwiCloud Trial Account is provisioned (with 60-day KC Enhanced license) by the KiwiCloud team by creating a trial-purpose account on the iMinKit platform and running an Official Migration Auto-Task on it. This trial-purpose iMinKit-side account is not equivalent to a customer’s iMinKit Official Account; its sole role is to initiate the iMinKit-to-KiwiCloud synchronization mechanism so the customer can authentically experience how iMinKit organization structure synchronizes to the KiwiCloud platform.

The KiwiCloud Trial Account is accessible to both the iMinKit platform and the KiwiCloud platform using the same email credentials.

2.4. KiwiCloud Standalone Account

An account on the KiwiCloud platform that was created independently of any migration operation, before the customer’s iMinKit Official Account had been migrated to the KiwiCloud platform. KiwiCloud Standalone Accounts were created by the KiwiCloud team for certain customers during March and April 2026 as an early access arrangement. From May 2026 onwards, KiwiCloud Standalone Accounts are no longer created for existing iMinKit customers, as this account type caused confusion by operating separately from the iMinKit platform without a clear migration pathway.

KiwiCloud Standalone Accounts fall into two patterns based on email registration:

• Most KiwiCloud Standalone Accounts share the same email address as the customer’s iMinKit Official Account. Such accounts are accessible to both the iMinKit platform and the KiwiCloud platform using the shared email address — but no migration operation has been performed, so the two platforms operate independently for this account.
• A few KiwiCloud Standalone Accounts were registered with a different email address from the customer’s iMinKit Official Account. Such accounts are accessible to the KiwiCloud platform only and cannot log in to the iMinKit platform.

2.5. KiwiCloud Bridging Account

A transitional KiwiCloud Migrated Account created by the KiwiCloud team for customers who have purchased iMin Devices running Android OS 14 and above (eligible for KMA mode, and for GMA mode if GMS-certified), which no longer support IMA mode, and need to begin managing these devices on the KiwiCloud platform before their iMinKit Official Account has been officially migrated.

The KiwiCloud Bridging Account is registered with a different email address from the customer’s iMinKit Official Account, and is accessible to both the iMinKit platform and the KiwiCloud platform. Since neither KMA nor GMA mode is supported by the iMinKit platform, the KiwiCloud platform is the only management platform for such devices, making this bridging account a necessary transitional solution.

The KiwiCloud Bridging Account is a temporary arrangement. Once the customer’s iMinKit Official Account has been officially migrated and becomes a KiwiCloud Migrated Account, the KiwiCloud Bridging Account should be consolidated accordingly.

This terminology framework focuses on authorizations and permissions on the iMinKit and KiwiCloud platforms. These terminologies are used to describe the roles, access rights, and operational scopes of accounts and users on both platforms.

There are two role tiers in this framework:

• Tier 1 – Super Admin (Super Administrator): the foundational role of an organization. Created automatically when an organization (for a customer) or a sub-organization (for a partner or subsidiary of the customer) is created on the iMinKit or KiwiCloud platform; the Main Account or Sub-account used to create the organization is its Super Admin. A Super Admin holds full management permission over its own organization and any sub-organizations beneath it, including the ability to create User Accounts and assign roles to them.
• Tier 2 – User Accounts: non-Super-Admin accounts (iMinKit User Accounts or KiwiCloud User Accounts) created by a Super Admin and assigned specific roles such as Ordinary Admin, scoped to the organization or sub-organization in which they were created. User Accounts are not Sub-accounts.

There are four Super Admin accounts that differ by sub-type (Cooperative or Controllable/Controlled), which determines APP-publishing rights. Cooperative Super Admins have permission to publish business applications for their organization and sub-organizations through APP policy configuration; Controllable/Controlled Super Admins do not. APP publishing functions reside on the iMinKit platform before migration and are migrated to the KiwiCloud platform during official migration; the publishing permission follows the same path. The Main Account created directly under each platform’s root node is automatically granted the Cooperative sub-type. For sub-organizations, the sub-type is chosen by the higher-level Super Admin who creates them — see the typical scenarios below.

3.1. iMinKit Super Admin (Cooperative)

A Super Admin on the iMinKit platform holding the Cooperative sub-type. Has APP-publishing permission for its organization and sub-organizations. Synonymous with iMinKit Cooperative Account.

3.2. iMinKit Super Admin (Controllable)

A Super Admin on the iMinKit platform holding the Controllable sub-type. Does not have APP-publishing permission; APP publishing must be governed by a higher-level iMinKit Super Admin (Cooperative). Synonymous with iMinKit Controllable Account.

3.3. KiwiCloud Super Admin (Cooperative)

A Super Admin on the KiwiCloud platform holding the Cooperative sub-type. Has APP-publishing permission for its organization and sub-organizations. Synonymous with KiwiCloud Cooperative Account.

3.4. KiwiCloud Super Admin (Controlled)

A Super Admin on the KiwiCloud platform holding the Controlled sub-type. Does not have APP-publishing permission; APP publishing must be governed by a higher-level KiwiCloud Super Admin (Cooperative). Synonymous with KiwiCloud Controlled Account. Note: KiwiCloud uses Controlled where iMinKit uses Controllable.

3.5. iMinKit User Account

A non-Super-Admin account on the iMinKit platform, created and assigned with specific role (e.g. an Ordinary Admin) by a Super Admin. Used for delegated operational tasks within the organization.

3.6. KiwiCloud User Account

A non-Super-Admin account on the KiwiCloud platform, created and assigned with specific role (e.g. an Ordinary Admin) by a Super Admin. KiwiCloud User Accounts enable multiple users to jointly manage devices, policies, and configurations on the KiwiCloud platform, with access controlled through the roles assigned by the Super Admin.

3.7. Typical Scenarios

The following two scenarios illustrate how the Super Admin sub-types are typically applied in real-world customer deployments:

3.8. Synchronization Behavior Between Platforms

Super Admins (Main Account and Sub-accounts) and User Accounts (iMinKit User Accounts and KiwiCloud User Accounts) follow different synchronization rules between the iMinKit and KiwiCloud platforms:

• Super Admin – synchronized in both migration phases. A Super Admin (and its sub-type – Cooperative or Controllable/Controlled) is synchronized from the iMinKit platform to the KiwiCloud platform during both official migration and post-migration (when a new sub-organization with a Super Admin is created on iMinKit after official migration).
• User Accounts – authorization not synchronized. iMinKit User Accounts (e.g., Ordinary Admins) are synchronized to the KiwiCloud platform as physical account entities during official migration, but without any roles or access permissions – the KiwiCloud Super Admin must assign roles and access permissions to these accounts on the KiwiCloud platform before they can access it. In the reverse direction, KiwiCloud User Accounts created directly on the KiwiCloud platform are not synchronized to the iMinKit platform – if equivalent roles are needed on iMinKit, the iMinKit Super Admin must create them locally. User Accounts created on iMinKit after official migration are not synchronized to the KiwiCloud platform. After migration, we therefore recommend creating User Accounts directly on the KiwiCloud platform (see Appendix 8 – Section 3).
• Asymmetric Super Admin relationship: An iMinKit Super Admin is always a KiwiCloud Super Admin (because Super Admins synchronize from iMinKit to KiwiCloud). However, a KiwiCloud Super Admin is not necessarily an iMinKit Super Admin — if the KiwiCloud Super Admin was created along with an organization or sub-organization directly and independently on the KiwiCloud platform, it has no corresponding iMinKit Super Admin and will not be synchronized back to iMinKit.

For these reasons, customers are recommended to manage organization structure and associated Super Admin accounts on the iMinKit platform after official migration.

After official migration, access to the KiwiCloud platform is governed by Super Admin synchronization from the iMinKit platform: every Super Admin on iMinKit is automatically synchronized to the KiwiCloud platform as a KiwiCloud Super Admin, with the same email credentials and the same APP-publishing sub-type (Cooperative or Controllable / Controlled). iMinKit User Accounts (e.g., Ordinary Admins) are also synchronized as physical account entities, but without any roles or access permissions — the corresponding KiwiCloud Super Admin must assign roles and access permissions to these accounts on the KiwiCloud platform before they can access it. User Accounts created on iMinKit after official migration are not synchronized to the KiwiCloud platform. After migration, we therefore recommend creating User Accounts directly on the KiwiCloud platform (see Appendix 8 – Section 3).

The following table summarizes how each iMinKit account type is treated on the KiwiCloud platform after migration. For the purposes of this section:

• Entity A refers to the customer’s top-level organization on iMinKit (whose Main Account is a level-1 iMinKit Official Account, held by an iMinKit Super Admin).
• Entity B refers to a partner or sub-organization of Entity A on iMinKit (whose account is a level-2 iMinKit Sub-account of Entity A, but functions as an iMinKit Official Account for Entity B itself, held by an iMinKit Super Admin for Entity B’s scope).

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. It provides the domains and ports required for network and firewall whitelisting to ensure devices and platform endpoints remain reachable during and after the migration. It is distributed to customers together with the Migration Playbook and related materials.

1. Endpoint Allow-list

The following domains and ports are required for network and firewall whitelisting prior to migration. Actual configuration should follow the customer’s network policy and project requirements.

KiwiCloud Diag is a diagnostic application uploaded by the KiwiCloud team to the iMin APP Store as a public APP. Customers can download and install it on iMin Devices to verify connectivity to KiwiCloud platform services — including the endpoints, ports, and regional service nodes listed in this Appendix. KiwiCloud Diag helps customers validate firewall configurations and network whitelisting in preparation for migration, identifying and resolving any blocked domains or ports before devices begin communicating with the KiwiCloud platform.

1.1. KiwiCloud (Web Application)

1.2. AWS IoT Core

1.3. AnyDesk

1.4. Others (Web Application Frontend)

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. It catalogues the risks identified for the iMinKit-to-KiwiCloud migration, along with their probability, impact, residual level, and the mitigation or contingency measures planned by the KiwiCloud team. It is distributed to customers together with the Migration Playbook and related materials.

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. It shows, side by side, how the iMinKit console changes once an account has been migrated to KiwiCloud. It is distributed to customers together with the Migration Playbook and related materials. Click any screenshot to view it at full size. (Screenshots show the English interface.)

1. Top Bar

Before migration, the account status shows “(non-migrated)” and no KiwiCloud login option is available. After migration, a “Login to KiwiCloud” shortcut appears alongside the “(Migrated)” status label.

BEFORE MIGRATION

Click to view full screenshot

AFTER MIGRATION

Click to view full screenshot

2. Navigation Menu

The left-hand navigation shrinks from 11 top-level modules to 6 once migration is complete.

BEFORE MIGRATION

Click to view full screenshot

AFTER MIGRATION

Click to view full screenshot

3. iMin Store

The iMin Store menu narrows from six sub-items to just “My Apps” — retained on iMinKit until December 31, 2026, 23:59 (see Section 2.1).

BEFORE MIGRATION

Click to view full screenshot

• My Apps
• Recommend Apps
• All Apps
• Blacklist Apps
• Ads Customisation
• Release Plan

AFTER MIGRATION

Click to view full screenshot

• My Apps

4. Device Management

Device Management is reduced to three sub-items: five items from the previous menu are no longer listed, and a new “Device Diagnostics” entry appears.

BEFORE MIGRATION

Click to view full screenshot

• Device List
• Remote Control
• Device Allocation
• Offline Notification
• Scheduled Tasks
• Operation Log
• Permission

AFTER MIGRATION

Click to view full screenshot

• Device List
• Device Diagnostics (new)
• Device Allocation

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. It walks through the customer-facing steps of submitting a Migration Application in the iMinKit console — the customer’s side of task 1.1 in Phase 1. It is distributed to customers together with the Migration Playbook and related materials. Click any screenshot to view it at full size. (Screenshots show the English interface.)

Migration Application — 3-Step Process

Submitting a migration request (“Submit Migration Request” on the iMinKit home page) walks the customer through three steps before the application is sent to the KiwiCloud team.

•

Entry Point: Submit Migration Request

Click to view full screenshot

Before migration, a persistent notice banner appears at the top of the iMinKit console: “iMinKit Device Management Capabilities Are Migrating to KiwiCloud”. From here, the customer can:

• View Notice and Download Guides — review migration announcements and reference materials
• Submit Migration Request — launches the 3-step application flow shown below

1

Readiness Check

Click to view full screenshot

The system automatically runs three checks before the customer can proceed:

• Check Migration Region — confirms the KiwiCloud regional node the account will migrate to (e.g., Singapore)
• Check Email Conflicts — verifies there is no existing KiwiCloud account under the same email
• Check App Blacklist — verifies iMin APP Store and Remote Assistance are not blacklisted

All checks must pass before continuing; a “Re-check” option is available if any item needs to be resolved first. Applications submitted before this check was introduced were not checked; those early applicants re-submit the application in Phase 2 (see Phase 2).

2

Review Requirements

Click to view full screenshot

The customer reviews and acknowledges two notices:

• Network Environment Risk Notice — flags potential risks from enterprise firewalls, local network conditions, and multi-location device fleets, with a link to the KiwiCloud Diag tool for pre-migration network testing (see Appendix 2)
• Employee Role Authorization Notice — refers to the employees’ User Accounts: they are migrated together with the account, but have no access to KiwiCloud until the Super Admin assigns them a role and access permissions after migration (see task 4.5 in the Playbook and Appendix 1, Post-Migration Authorization Model)

3

Submit Application

Click to view full screenshot

The customer fills in the final application details:

• Migration Schedule — device peak and off-peak hours
• Migration Project Owner — owner name, phone, and email
• Additional Notes — optional remarks or special instructions

Once submitted, the request moves forward for KiwiCloud team review.

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. It provides migration guidance for customers who operate a SoftPOS (payment device) business. It is distributed to customers together with the Migration Playbook and related materials.

1. Who This Appendix Is For

This Appendix is for customers who operate a SoftPOS (payment device) business. For all other customers, the standard migration process in Section 3 of the Playbook applies.

2. Why These Customers Need a Different Approach

The devices of these customers must run in an environment that meets higher security standards. As a result, these customers generally do not allow application upgrades on their devices, and place the iMin APP Store and Remote Assistance on the APP blacklist.

This matters for migration because the upgrade of these two applications is the mechanism by which the migration itself is enabled on devices, and blacklisting them prevents the upgrade policy from being applied (see Section 2.5).

3. What Will Be Needed After Migration

After migration, application upgrades need to be opened gradually — device by device, or batch by batch — rather than for all devices at once.

4. Current Status

About This Document

This Appendix is a companion document to the KiwiCloud Migration Playbook. After migration, the way devices are enrolled, apps are upgraded, user accounts are created and remote access works differs from iMinKit. This guide covers the four things customers ask about most after migration — where their devices are, how to release app upgrades, how to create user accounts, and how to use unattended remote access — each with step-by-step screenshots. It is distributed to customers together with the Migration Playbook and related materials. (Screenshots show the English interface of a demo account.)

1. Where Are My Devices?

If you cannot find a newly purchased device in Device Management → Device List, that is expected: new devices first appear in Enrollment → Device Status. A device is only brought under management once you have configured an enrollment method (Enrollment) and the device has been enrolled into KiwiCloud — the Device List contains only devices that have been enrolled and brought under management. After migration, devices appear as follows:

• IMA devices (Android OS 13 or below) activated before migration appear in Device Management → Device List.
• IMA devices not activated before migration appear in Enrollment → Device Status → To Be Managed → Candidate.
• IMA devices newly activated after migration appear in Enrollment → Device Status → To Be Managed → Unenrolled. Enroll them via IMA Zero-Touch; GMS-certified devices can alternatively use GMA QR Enrollment or GMA Zero-Touch Enrollment.
• Android OS 14+ devices for which no enrollment method that includes the device SN (e.g., GMA QR Enrollment or KMA Zero-Touch Enrollment) has been configured appear in Enrollment → Device Status → To Be Managed → Candidate.
• Android OS 14+ devices for which such an enrollment method has been configured appear in Enrollment → Device Status → To Be Managed → Unenrolled.

How to enroll your devices

Enrollment links a device to your KC account so you can see and manage it remotely. iMinKit didn’t need this step because it only worked on iMin Devices that were already linked at the factory. There are two ways to enroll a device: QR code or Zero-touch Enrollment (ZTE); this guide uses Zero-touch.

1. Go to Enrollment > Zero-touch > KiwiCloud Zero-touch and choose Enrollment Configuration.

2. Select the device SNs you want to enroll and click Submit.

3. Ask store staff to restart each device.
4. Check your devices under Enrollment > Device Status > Managed. All successfully enrolled devices are shown here.

2. How Do I Release an App Upgrade?

Good news: keep uploading and updating your APKs in iMinKit as usual. They sync to KiwiCloud automatically, and you release them from the KiwiCloud console, with an app upgrade policy:

1. Upload the new version in iMinKit. Go to iMin Store > My Apps and click Add app to upload the new version of your APK.

2. Find your uploaded APK in App Management > My App in KiwiCloud. It is synchronized automatically.
3. Go to App Management > App Release Policy, click Create App Policy and choose KC App Policy.

4. Choose the app and its latest version, then click Next Step.

5. Apply it to a device group (e.g. “test”) or a specific device, and click Submit.

3. How Do I Create User Accounts?

Give each team member their own login instead of sharing a single account. First, it helps to know how user accounts are synchronized between iMinKit and KiwiCloud:

We therefore recommend creating user accounts directly on KiwiCloud after migration, as follows. If a user account migrated from iMinKit cannot log in, ask a Super Admin to assign it a role and access permissions on KiwiCloud (see the FAQ and Appendix 1 – Post-Migration Authorization Model).

1. Go to System Management > Organization Management > Role Management and click New Roles.

2. Define the role’s permissions.

3. Go to System Management > Organization Management > User Management and click Create Account to create a user account for each person.

4. When creating the account, select the role you created, e.g. Admin (full access) or Operator (manage devices and apps access).

4. How Do I Use Unattended Remote Access?

• Before migration: the iMin Tech-developed Remote Assistance required the end user to enable the feature on the device.
• After migration: the remote assistance service has moved to AnyDesk. You set an unattended remote access password once in the KiwiCloud console, and every device added to the group gets the same setting automatically; administrators then connect with that password. End users do not need to do anything on the device.
• Why it changed: so that you have full control of your devices. Before migration, if an end user inadvertently stopped the unattended remote access function on the device, you could no longer access the device remotely with it.

Before you start

• The devices must be enrolled (see section 1).
• On the device: KMA devices come with AnyDesk preinstalled. IMA devices need AnyDesk and the latest Remote Assistance app installed.
• Check the AnyDesk ID: a device can only be accessed remotely if it shows an AnyDesk ID in Device Management > Device List.
• On your laptop: install AnyDesk.

Set up once (console)

1. Go to Device Management > Device Policy, click Create Policy and choose KMA Policy.

2. Scroll to the bottom, turn on Remote Assistance and set a password. Click Next Step.

3. Deploy it to a device group (e.g. “test”) or a specific device.

Every time you connect

1. Go to Device Management > Device List, find your device SN, open the Action tab and choose Remote Assistance.

2. Enter the password. You’re now connected to the device remotely.

Need help?

Contact your dedicated CSE (Customer Service Engineer), or write to contact@kiwi.cloud. See also the FAQ.

Answers to the questions customers ask most often about the iMinKit → KiwiCloud migration, grouped by topic. They are aligned with this Playbook and its Appendixes. For anything not covered here, contact your dedicated CSE (Customer Service Engineer) or contact@kiwi.cloud.

1. Migration Policy & Timeline

2. Who Needs to Migrate

3. License & Free Authorization

4. Scope & Process

5. Accounts & Permissions

6. Application Management

7. Device Management

8. Remote Assistance