Migration strategies for deprecating in-house scripting language

Question

We have a scripting language that we use internally for many things. It began as a simple evaluation statements for dynamic labels to become a Turing complete language used pervasively throughout our system.

Problem is that it was never designed for this and it shows. Development environment is anemic, scripts produced are not testable and still to this day there is not formal definition of the language.

A growing sentiment among the language's users feel that it has done it's job and it's time to let go but we are faced with a difficult challenge to migrate existing codebase to whatever new solution would be devised. This very argument is used against the idea of migrating.

Have you ever faced a similar situation ? and if so what strategies did you use to stop usage of the old and promote the new ?

One last thing (thanks Morons) is that many of these scripts are not documented and their original purpose is lost though they are still in active use. The scripts are also used at customer sites to customize the system so we have literally thousands of these scripts a large portion of which is not under source control or any versionning mechanism for that matter.

---

Accepted answer.

Difficult choice this is. All answers were good and sound advice though I think the best lies somewhat of a hybrid of Moron's and Oliver's.

I ended-up accepting Oliver's because it is the answer that stands the best chance of getting accepted higher up (ha! politics!). Packaging the old scripting environment in a callable statement that can be integrated in the new environment would provide a quick and easy upgrade path.

Once done we can control better creation of new scripts by displaying warnings or disallowing all-together old scripts from being edited or created forcing to go with the new language.

Thanks all for your input !