Topic

ActiveX Migration

Topic page for teams deciding how to keep, wrap, or replace existing ActiveX / OCX assets without forcing an all-at-once rewrite.

What this topic is for

Projects with existing ActiveX / OCX assets often look like a false choice between rewriting everything and touching nothing. In practice, there are several middle paths.

  • keep the current component and maintain it
  • wrap it so newer code can use it more safely
  • replace surrounding parts in stages
  • redesign only the native boundary first

Common questions on this topic

  • how long should an existing ActiveX / OCX asset be kept alive
  • how should newer .NET code interact with it safely
  • which parts should be replaced now and which should stay for the moment
  • how should COM responsibilities and thread boundaries be separated

Typical direction

It is often more effective to clarify the current boundaries first and decide where maintenance, wrapping, or staged replacement makes sense than to jump straight to a full rewrite. The related service pages and articles linked from this page are meant to support that comparison.

Get in Touch

If this page is close to the situation you are dealing with, please contact us with the current context and what kind of support you need.

Back to Home