Many business apps still run on Lotus Notes, Microsoft Access, or Excel macros built years ago. These apps tend to cause the same problems:

• Adding a field or changing a screen requires a quote from an outside vendor, so teams keep using the old screens.
• Each department keeps its own copy of the data in spreadsheets, and nobody knows which file is current.
• Servers, extended OS support, and vendor maintenance contracts still cost money, even when the app hardly changes.
• The person who built the app has left, and nobody else can read the Notes formulas or Access VBA.

When your business cannot fix these problems quickly, teams start using their own tools and a complicated untouchable web of shadow IT grows.

This guide will give you a starting point for moving business apps away from legacy systems such as free standing mySQL databases, excel, or Microsoft Access. It then walks through a migration to Kintone, from creating the App to loading data.

Why Legacy Business Apps Get Replaced

Replacement projects often start with an event such as a server refresh, an audit finding, the end of a support contract, or a merger that brings in a second set of systems.

If the replacement takes months, business teams may start using their own tools, such as a SaaS product paid for with a company card or a no-code app on a personal account. To prevent this, the replacement platform needs to meet both of the following requirements:

1. Business teams can build and change their own apps without filing a ticket for every field.
2. IT keeps control of identity, permissions, and logs.

Migrating an App to Kintone, Step by Step

The following example migrates an app from a legacy system, where the source data has already been exported to a CSV file. Notes views, Access tables, and SharePoint lists can all be exported to CSV.

Step 1: Create the App

Create Apps from CSV files, by hand, or by the Kintone MCP Server .

It may be useful to include a field that stores the record ID from the legacy system, such as Legacy_ID, and turn on its Prohibit duplicate values option. If the migration script runs twice, the second run fails on duplicates instead of creating them. The field can also be used as a key for later updates.

Create the App From a File

Kintone can create an App directly from an Excel or CSV file. The first row of the file becomes the field names, Kintone suggests a field type for each column, and the remaining rows are imported as records. For flat data with a few thousand rows, this may be the only step needed.

Check the following after the App is created:

• Field codes are assigned automatically and do not match the column names. To load data with a script later, change the field codes to match the script.
• Suggested field types may not fit the data. For example, a column with only a few distinct values may become a Drop-down or Radio button field, and a column of login names does not become a User selection field. Field types cannot be changed after a field is created, so delete the field and add it again with the correct type.

For more information, refer to the Creating App from Excel File article on the Kintone Help site.

Step 2: Set Up Groups and Permissions Before Adding Users

Grant permissions to groups instead of individual users. When someone joins or leaves a team, only the group membership changes, and the App settings stay the same.

1. Create a group for each team that needs different access, such as procurement. On the Users & System Administration page, open Groups (Roles) and add the group and its members. The group code is used to specify the group in permission settings and in the REST API. Departments can be used the same way. For more information, refer to the Configuring Groups (Roles) article on the Kintone Help site.
2. Open the App settings screen, and set the permissions on the App Settings tab:
   • App permissions: Who can view, add, edit, and delete records, and who can manage the App.
   • Record permissions: Who can view or edit records that match a condition, such as records created by a specific department.
   • Field permissions: Who can view or edit a specific field.
3. Click Update App to apply the settings.

For more information, refer to the Managing Permissions article on the Kintone Help site.

Step 3: Load the Data

If the data was not imported along with the CSV, or requires automated importing, cli-kintone or using the REST API is recommended.

For cli-kintone, refer to the Import Data with the Command Line Tool article.

Step 4: Connect SSO, Provisioning, and Notifications

Connect the new App to the identity provider and tools the company already uses:

• Single sign-on: Configure SAML authentication with Okta or Microsoft Entra ID .
• User provisioning: Sync users from Okta or Microsoft Entra ID . Users disabled in the identity provider lose access to Kintone.
• Notifications: Send record events to other services with webhooks , or post status updates to Slack .
• Audit logs: Check who changed Apps, records, and Spaces. For more information, refer to the Checking Kintone Audit Logs article on the Kintone Help site.

Rolling Out: Inventory, Prioritize, Pilot, and Scale

Migrate legacy apps in stages instead of all at once, so problems can be found and fixed early. The following four phases are an example.

1. Inventory

List every business app, including ones IT did not build. Record the following for each app:

• Owner and number of active users
• Data volume and attachments
• Connections to other systems
• Business impact if the app is unavailable

Include apps that teams built on their own. If they are left out, the same teams may build unmanaged tools again after the migration.

2. Prioritize

Rate each app on migration effort and on the risk of leaving it in place. Good first candidates have an owner who wants the change, mostly flat data, and a deadline, such as a server scheduled for retirement. Leave the most complex app for later, and use the first migration to check the process.

3. Pilot One App

Migrate one app using the steps in Migrating an App to Kintone, Step by Step . Run the old and new apps in parallel for a short period and compare the results. Record the field mapping rules, permission settings, and naming conventions so the next team can reuse them.

4. Scale

Before more teams start building, decide the following:

• Who can create Apps, and in which Spaces
• Which App templates and permission settings are standard
• Who reviews the audit logs, and how often

Once these rules are set, IT does not need to review each App that business teams build or change.

Frequently Asked Questions

Can Kintone import data from Lotus Notes or Microsoft Access?

While Kintone does not connect to Notes or Access directly, export the data to CSV or Excel first, then create an App from the file or load it with the REST API or cli-kintone.

Can IT restrict who creates Apps?

Yes. System administrators can choose which users, groups, or departments can create Apps. App creation can also be limited to specific Spaces or App groups.

Is the Kintone MCP server officially supported?

The Kintone MCP server is an official open-source project, but it is not covered by the API support desk. Report bugs and feature requests on GitHub Issues .

What does the developer license include?

The developer license is free and valid for one year. Licenses for active developer domains are extended for another year. Each developer domain supports up to five users and 25 GB of storage, and SSO settings can be enabled. The license is for application development only, and cannot be used for commercial use. Technical support is not included. For details, refer to the Kintone Developer License page.

Start With One App

To evaluate Kintone as a migration target, rebuild one real app. Pick an app from the inventory, recreate it in a developer environment, and load a test copy of its data using the steps above.

To plan a larger migration with a Kintone specialist, request a demo.

For API references, tutorials, and SDKs, see the Kintone Developer Program top page.