Most manufacturers in Gifu and Aichi that we speak to have at least one system they know needs replacing. The reasons it has not been replaced yet are usually the same: the system still works, the person who built it has retired, and nobody wants to be responsible for the disruption of changing it. This guide is for the operations manager or IT lead who has been handed that problem and needs to think through it clearly.
Start with a dependency map, not a replacement plan ¶
Before you decide what to replace the old system with, you need to understand what depends on it. Legacy systems in manufacturing environments often have undocumented connections to other systems, manual workarounds that have become load-bearing, and data formats that nothing else in the organisation can read. Spend two to three weeks mapping these dependencies before you write a single line of requirements. The map will tell you more about the real scope of the project than any vendor demo.
Understand your data residency obligations under Japanese law ¶
If your system handles personal data, you need to review your obligations under the Act on the Protection of Personal Information (個人情報保護法) before choosing a replacement platform. Cloud platforms operated by foreign companies may store data outside Japan, which can create compliance issues depending on your industry and the nature of the data. This is not a reason to avoid cloud platforms, but it is a reason to read the data processing agreements carefully before signing.
Plan for a parallel running period ¶
The most common mistake in system migrations is switching off the old system too quickly. A parallel running period, where both the old and new systems operate simultaneously, gives you a safety net while your team builds confidence in the new environment. For manufacturing scheduling systems, we typically recommend a minimum of four weeks of parallel running before decommissioning the old system. This is inconvenient and costs money, but it is far less expensive than a failed cutover during a production run.
Write your documentation before go-live, not after ¶
Documentation written after go-live is documentation that never gets written. Build the documentation requirement into the project scope from the start, and assign a specific person to own it. For clients who have no dedicated IT staff, we write the documentation ourselves as part of the engagement, in Japanese and English, at a level of detail that a non-specialist can follow. The goal is that the system can be understood and maintained by someone who was not involved in the migration.
The 90-day period after go-live is when things actually break ¶
Every system migration has a post-go-live period where unexpected issues surface. Users find edge cases the testing did not cover. Integrations behave differently under real load. Data that looked clean in the test environment turns out to have exceptions. Build a formal support period into your project plan and make sure you know who is responsible for responding to issues during that window. At Knot Lab Mesh, we include a 90-day support window in every migration engagement for exactly this reason.
A legacy system migration is a significant undertaking, but it is a manageable one if the planning is thorough. The organisations that struggle most are those that underestimate the dependency mapping phase and overestimate how quickly their team will adapt to a new system. Start slow, document everything, and keep the old system running longer than you think you need to.