Do you want to do it yourself or have us do it? In between those two extremes is a scale of mutual involvement.
The minimum engagement is a "license only" arrangement whereby you get a license for the tool and throw your own resources at the project. Depending on how you want to measure costs (there's the "D" word again), this might be the least expensive approach. Then again, it might not be.
Our tools are designed to be extendable. For one thing, that's how we can continue to add support for more and more 3rd party components. In some cases, increasing the available automation in the tool (via some custom work by our product team for your specific set of needs) can reduce the overall cost compared to using your resources with a bare-bones license.
Suppose your resources are already committed to other projects. Or they lack experience in migration issues. Or you'd rather have a root canal than work on old code. Whatever. Our engagement models go from "license only" to "full functional equivalence" and several intermediate levels:
- Bare-bones, license only: go for it.
It comes with support so our engineers can help you with some of the hard spots.
- License with additional automation:
we can help you identify areas where increasing the available automation through specific customizations can improve your team's productivity.
- Compile-only: We'll take your code and get the migrated app to compile.
Some code will be stubbed out. But you won't have to sort through Visual Studio compile errors.
- Visual equivalence: The app will be up and running--screens will render and controls will respond to events.
You'll have to verify that it actually works the way the original app did.
- Functional equivalence: the full meal deal.
We migrate the app and fix bugs until it passes your test suite from the original app. All you have to do is accept the final code.
Complexity and size
All "hello worlds" are basically identical, but that's where similarities between apps end. No two are alike.
Some are small and simple, others are like this guy.
A lot of legacy apps were initially created before the current era of OOP, and patterns like MVC or MVVM--or even practices like DRY (don't repeat yourself) just aren't in that old code.
You have duplicate code, dead code, tangled code, methods/functions/subroutines that do dozens of unrelated things, global variables that come to haunt your darkest hours.
Basically it's crap. And over the years they have grown like Georgia kudzu in a junk yard. We've seen monolithic apps north of 5 million lines of code.
Apps with bits and pieces still tucked away from the days of DOS. And because multiple people worked on it with multiple coding philosophies you wind up with something truly awful to gaze upon.
We began with VB6 to VB.NET. Then we added VB6 to C#. And C# to HTML. And even more like PowerBuilder and Silverlight. Each of those increased the challenge for our product team to solve thorny problems.
None of this is easy, by any stretch. But VB6 to VB.NET is a far more constrained problem set than C# to HTML.
All our supported transformations have unique problems, but some require significant more investment to develop than others. For that reason, they have different prices.
How about some examples?
Let's take some very different scenarios based on actual customer projects.
Financial firm (large app.)
- Technology: VB6 to HTML
- Size/Complexity: 300 screens, over 1MLOC, high complexity
- Engagement: Full functional equivalence
- Cost: $2.5M
ISV (medium app.)
- Technology: VB6 to C#/Winforms
- Size: 50 screens, 200KLOC, medium complexity
- Engagement: License only
- Cost: $25,000
Local government (small app.)
- Technology: VB6 to HTML5
- Size: 5 screens 50KLOC, low complexity
- Engagement: Compilation
- Cost: $40,000
Healthcare (medium app.)
- Technology: PowerBuilder to ASP.NET Core
- Size: 75 screens, 350KLOC, high complexity
- Engagement: Visual equivalence
- Cost: $500,000
How do I get a real cost?
Because this is a three variable model, we need to collaborate with you to develop a cost.
There are a couple of ways we can do this:
- Run our assessment tool and give us the results.
For some transformations, this will provide sufficient data to give you a ballpark for all the different engagement models. Other transformations will require some additional information we'll need to collect in a quick call with one of our engineers. What's a ballpark? It's an approximation of our costs plus or minus about 20%. Of course, you'll have to provide some resources as well--from basically all of them for a bare bones license engagement model to a minimum amount for full functional equivalence (see above). Adding your internal estimated costs to our ballpark price will give you a reasonable "back of the envelope" estimate of the project cost. We can help you with timeframes as well, based on our experience with these kinds of migrations.
- Get a migration blueprint.
This is a paid engagement for one of our senior migration engineers to come on-site and review your code. As part of that they will migrate some of your code (think of it as a proof of concept), identify all the hidden migration issues and suggest mitigation strategies, and create a plan for the migration, including schedule and resource requirements. With that level of detail we can include a fixed-price, fixed-schedule proposal for our part of the project, assuming you want some assistance. This is--for most customers--the most popular model for getting rid of legacy code.
If you've read this far, it's because either you're an insomniac trying to get to dreamland, or you've got a legacy code problem.
Given the latter (can't help with the former), you have basically four (4) choices:
- Do nothing.
Nada. Kick the can down the road and hope someone solves it later. Not advised.
- Replace the app with off-the-shelf software.
- Rewrite the app.
If you are ok with the well-documented risk of writing new code, then go for it. Note: no one says "I do" expecting to get divorced, but divorce rates run 50%. Go figure. If (I didn't say "when") your project goes sideways, join many of our customers by abandoning it and getting a migration instead.
- Migrate the app.
That quickly (and affordably) gets you a working version that's out from under the weight of the legacy language, platform, and dependencies. Now you can make improvements to refactor or enhance. Preserves your business logic and doesn't introduce new bugs. Overall, a great idea.
To learn more, call us.