Walk into many Japanese companies, from SMEs to divisions of large corporations, and you will find critical business processes running on Visual Basic 6.0 (VB6) applications or Excel workbooks full of VBA macros. They calculate quotes, schedule production, manage inventory and produce reports. They were often built years ago by a capable employee who understood both the business and the code.
These tools served their companies well. But today they are among the most common legacy IT systems in Japan, and a growing source of risk. This article explains why VB6 migration and VBA modernisation deserve attention now, what options exist, and how to migrate without disrupting the business.
Why VB6 and VBA are still everywhere
VB6 and VBA made it possible for non-specialists to build useful business tools quickly. In Japan, where many companies prefer systems tailored precisely to their own workflows, this flexibility was especially valuable. The result is a large base of custom applications and macro-driven workbooks that are deeply embedded in daily operations.
The problem is not that these tools are old. It is that they are increasingly difficult to maintain, secure and connect to the rest of the business.
The risks of staying on VB6 and VBA
Dependence on a few individuals (属人化)
In Japanese, the term zokujinka (属人化) describes work that depends on specific individuals. Many VB6 and VBA tools are understood by only one or two people. When they retire or leave, the company may be unable to fix problems or make changes. With Japan’s workforce aging, this risk grows every year.
An unsupported development environment
Microsoft ended support for the VB6 development environment (IDE) on 8 April 2008. The VB6 runtime is still supported for the lifetime of current Windows versions, including Windows 11, so existing applications usually continue to run, although that support is limited to serious regressions and critical security issues. But the tools used to build and maintain them are unsupported, and developers with VB6 skills are increasingly rare.
Platform changes that break old code
- 32-bit limitations: VB6 produces 32-bit applications only, which limits memory use and compatibility with some modern components.
- 64-bit Office: 64-bit Office is now the standard installation. VBA code that calls Windows APIs must be updated to run correctly: Declare statements need the PtrSafe keyword, and handles and pointers should use LongPtr.
- Windows upgrades: Windows 10 reached end of support on 14 October 2025 (as of September 2026, consumer Extended Security Updates run until 12 October 2027), and moving to Windows 11 has exposed compatibility issues with older components and drivers.
- Scripting and macro security changes: Since 2022, Office blocks VBA macros in files downloaded from the internet by default. Microsoft is also retiring VBScript in phases: it is an optional feature enabled by default from Windows 11 24H2, is expected to be disabled by default around 2026 to 2027, and will later be removed. VBA itself is not being deprecated, but VBA code that calls .vbs files or uses the VBScript RegExp library needs updating (as of September 2026).
Security and compliance gaps
Macro-enabled files are a common route for malware. Legacy applications may also store data without proper access control or audit trails, which creates problems for security and compliance.
Barriers to DX
Perhaps most importantly, VB6 and VBA tools are hard to integrate with cloud services, ERP systems, mobile devices and AI. METI’s 2018 DX Report warned that legacy systems could hold back Japanese companies and cost the economy up to ¥12 trillion a year from 2025, the so-called “2025 Digital Cliff.” Removing these bottlenecks is often the first practical step in digital transformation.
Modern platform options
There is no single right destination. The best choice depends on the tool’s complexity, users and future needs.
| Option | Best suited for | Considerations |
|---|---|---|
| .NET desktop (VB.NET or C#) | Complex desktop applications that must stay on Windows | Closest path from VB6; supported and familiar to Windows developers |
| Web application | Tools used by many people or several locations | Accessible from any browser; easier central maintenance |
| Low-code platforms (for example, Microsoft Power Apps and Power Automate) | Simple forms, approvals and workflows | Fast to build; watch licensing costs and governance |
| Python or modern scripting | Data processing, reporting and analytics currently done in VBA | Strong data and AI libraries; needs proper deployment |
| Packaged software or SaaS | Common functions such as accounting, CRM or production management | Adapt processes to standard features rather than rebuilding custom logic |
| Retire | Tools no longer needed | Often a surprising share of the inventory |
Migration approaches
Automated conversion. Tools exist that convert VB6 code to .NET. They can speed up large migrations, but converted code usually needs significant manual work and may carry old design problems forward.
Rewrite. Rebuilding the application on a modern platform, using the old system as a specification. This takes longer but produces cleaner, more maintainable software.
Replace. Moving to packaged software or SaaS, often the most cost-effective option for standard business functions.
Incremental modernisation. Replacing functions step by step while the old system keeps running, reducing risk for large or critical applications.
A step-by-step approach to VB6 migration and VBA modernisation
- Inventory everything. List every VB6 application and important Excel/VBA workbook: who uses it, what it does, what data it touches and who understands it. Many companies discover far more tools than they expected.
- Assess risk and value. Prioritise tools that are business-critical, depend on one person, or block other improvements.
- Document business logic. Capture the rules hidden in the code, such as pricing formulas, scheduling logic and exception handling. Interview users and the original developers while they are still available.
- Choose the target for each tool. Rewrite, convert, replace, move to low-code or retire.
- Migrate in stages. Start with a low-risk, high-value tool to prove the approach.
- Test thoroughly. Run old and new systems in parallel and compare outputs, especially for calculations.
- Train users and decommission. Support users through the change, then retire the old tool so it does not continue in the background.
Resourcing the work
Many Japanese companies lack developers with both VB6 knowledge and modern platform skills. Options include training internal staff, working with domestic system integrators, or partnering with experienced offshore teams, including in India, where large numbers of engineers work with both legacy and modern Microsoft technologies. A combination often works best: internal staff own business knowledge and testing, while a partner provides migration capacity.
Conclusion
VB6 applications and VBA macros helped Japanese companies build tools that fitted their businesses precisely. But their risks, from dependence on individuals to security gaps and platform changes, are increasing. A structured modernisation programme turns these hidden liabilities into maintainable, connected systems, and clears the way for broader DX.