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 !

  • 4
    When I read the "one last thing (thanks Morons)", I thought you were commenting on the intelligence of the original designer.
    – Kyle
    Dec 8 '11 at 3:58
  • 2
    :-D no, though I did feel kinna weird writing it and hesitated for a while. Then again he choose the name so I guess it's OK !
    – Newtopian
    Dec 8 '11 at 4:03
  • 1
    It's OK!! ......
    – Morons
    Dec 8 '11 at 13:34

Another approach would be to port your scripting run time to the new scripting language of choice and provide ways for executing legacy scripts within the new language.

LegacyRuntime.execute(String script);

Being able to mix old and new code should ease the transition.


The fact that you are dealing with a custom scripting language is irrelevant. You are migrating a set of scripts from one language to another.

There are 2 basic strategies:

1) Take an on large effort to convert all the scripts upfront (as a project)

2) As you need to make changes to particular scripts, rewrite them in the new language. After some time, when there is only a few scripts left in the original language, go ahead an take on a project to finish those off. *

Either way you need to set a hard and fast rule: No New code is written in the legacy language.

*You may also set a rule on how much you are allowed to edit before having to re-write the whole thing, But this is likely to be abused as a loop hole.

  • I guess I forgot to mention that a lot of the scripts in there have a purpose but that knowledge disappeared with it's creator when they left the company.
    – Newtopian
    Dec 8 '11 at 3:52
  • 1
    This Doesn't change anything... You are going to need to understand the code at some point. And you are going to need the Change the code at some point as well. (Unless of course, no one on the team plans to be around for that :-)
    – Morons
    Dec 8 '11 at 3:57
  • 1
    With a very simple strategy it will be less likely there will be loopholes to be abused. As a addition to Morons strategy I would try to get them all in version control before doing anything.
    – refro
    Dec 8 '11 at 7:06
  • @refro I agree with you but unfortunately it would be near impossible. There are probably a dozen different storage format for these scripts and none are very SCM friendly. The script is often presented as a base 64 blob that has to be loaded in the compatible editor. But mostly it is because the scripts can be edited by customers directly and are stored locally in their database. There is a (suspected) large swath of scripts we do not even know exist. that said the language is so difficult to work with I doubt many customers invested much in to it.
    – Newtopian
    Dec 8 '11 at 7:40

I had such an experience.

My approach was to reverse-engineer the language implementation, deriving a more or less formal specification for its syntax and semantics (imagine deconstructing a BNF out of a handwritten parser in Fortran77, with several thousands of keywords). Then I've implemented a compiler for this language, translating it into an idiomatic Lua code (even preserving most of the comments).

You can choose any suitable popular scripting language or implement your own better designed DSL. Compiler could be used as a transparent translation layer (keeping the legacy scripts intact) or for rewriting the scripts for a better further maintenance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.