How to choose a modernization approach

I've written a ton of content about why you should modernize legacy apps.

Now I want to talk a bit about how.

Back in February of this year (2023), we got acquired by Growth Acceleration Partners (GAP) of Austin, TX. GAP picked up all our application modernization tools and people while Snowflake got all our data modernization tools and people. 

It was hard to say goodbye to people I've known and worked with for over a decade.

But joining GAP has been great. They bring a lot of things to our smaller table, including fresh eyes and perspectives on what we (the old Mobilize crowd they acquired) do, as well as how we do it. There's nothing like having someone ask "Why do you do it this way? Why do you call it that?"  to get you re-thinking old decisions and concepts.

In light of that, here's some changes or at least new ways of thinking about what we offer:

New branding for Mobilize.Net

Not that this is the most important thing, but it's certainly clarifying. You'll start seeing the name GAPMobilize in our communications. Why? Well, lawyers really.  But also because calling ourselves Mobilize.Net in future doesn't recognize that we're part of GAP now; and calling ourselves GAP is super confusing because GAP's brand up to now hasn't focused on 90s legacy modernization (note we're not in the jeans business at all). So GAPMobilize for the time being which we hope will avoid any confusion about who we are and what we do.

How about some love for a rewrite?

For over a decade I've been yelling into the void that automated code migration beats a ground-up rewrite every time. In cost, time, and risk. Given that, why would anyone ever rewrite a legacy app? Ok, let me be clear:

There are perfectly good reasons to rewrite a legacy app. I'll get into this in more detail in a future post, but the point to make here is that with our connection to GAP, we can now offer this as a service. 

That's right: we can rewrite your app for you. You can keep your A and B teams working on the new stuff, and we can bring a team of super-experienced engineers to rewrite it to your specifications. We can do a full-on ground-up all new code rewrite or a hybrid model, where we use tools and our migration expertise to, say, migrate all the business logic into a standalone service and write all new front-end code from scratch. If you can think of it, we can help build it.

New service offerings for migration projects

While historically we've always focused on tool building for migration, we've also always offered limited services to help our customers with their modernization requirements. Now as part of our new corporate structure, we're able to offer a wider and deeper bench of services, which I've outlined below:

License Only

This is available for migrations from VB6 to .NET Framework, targeting either C# or VB.NET with our Visual Basic Upgrade Companion which you can run on your code. You can try it out with a free trial (good for up to 10,000 lines of VB6 code) but a license is available for any size project (note the cost is determined by the size of the application, not the number of users). 

In this use case, you run the tool against a VB6 solution of 1 or more VB projects; it will create a new code base in a directory of your choosing. You then open that new Visual Studio solution file and start dealing with the inevitable errors, warnings, and issues that will await you. I would say this is best for applications under 100K lines of code. Anything larger than that will be quite challenging for a team who is not experienced in this particular scenario. 

You can also license our WebMAP product for C# Winforms, PowerBuilder, or other transformations. This product is not available as a trial (and there are lots of good reasons for this)^[1], but we can help you with a demo of the tool on your code so you can see how it works. You can also download and try out our sample code for both the VBUC and WebMAP. 

Engineering Ready

Briefly: it's ready for your engineering team to take over the project. We do the first part and you do the rest: Our team will run your complete code base through the appropriate GAPMobilize automated migration tool(s) and deliver you the resulting code. The code will be incompletely migrated (see below), but will compile in Visual Studio with no errors.

Note that doesn't mean it will run, it almost certainly will not. See below to understand why.

This is a major milestone in a migration project but is more “end of the beginning” rather than “the beginning of the end.”^[2]

There are a lot of different ways to tackle a legacy code migration project. You can google it yourself. But--unlike I suppose almost everyone else--we exclusively do migrations based on pretty well-baked tooling. Our philosophy from the founding was "what if we could make a migration tool that worked more like a compiler and less like regular expressions?" Therefore we build tools that use the entire application context and create a symbolic representation of all the code. 

What has that got to do with a migration delivery?

Just this: we use a big bang approach to migration. We don't migrate a solution one file at a time; we migrate all of them. That means that post-migration Visual Studio will generate a truckload of compilation errors:

• Errors from syntactic breaks from one language to another
• Errors from invalid casts from VB late binding
• Errors from properties, methods, and events that have no corollary in the target platform
• Errors from calls into dependencies like libraries that don't exist on the target platform
• And so on.

These errors can't be addressed by changing the migration tool; they require human intervention. Imagine, for example, that you had a VB6 application that used a 3rd party component that, hypothetically, drew a 3D object on a form, using a binary database of objects encoded in a proprietary data format. Now convert that VB6 form to a Windows form. The new C# code referencing that 3D drawing library won't work because it doesn't exist in .NET Framework and the company that created it in 1992 is long gone. 

You can't convert that code. 

You have to replace it. 

Therefore we provide Engineering Ready--we will convert all your code, but create stubs for the parts that can't convert. (We used to call this service "Compilation" but we felt the name could lead to confusion.) You can read more about it here. 

Alpha and Beta Ready

Following Engineering Ready, two release levels are available to choose between: Alpha and Beta Ready. Both Alpha Ready and Beta Ready require the creation of a suite of functional tests running in an automated testing harness^[1].

Alpha and Beta Ready delivery levels let you choose how much developer-level testing is completed by the GAPMobilize team before you let your own users begin testing.

In these migration projects, GAPMobilize migrates the code, creates new or revised code for all non-automated scenarios, and a specific number of customer-defined test cases will be run until they pass in the modernized application. The only difference between Alpha and Beta is the number of functional tests that must pass before the application source code is delivered to you to finish.

You determine the test coverage level desired before taking ownership of the application code:

• Alpha Ready: only a few screens/forms in the main application will load. Alpha requires sufficient functional tests to exercise approximately 30% of the source code. 
• Beta Ready: most screens will render and the application will run, but bugs will remain to be found. Beta requires sufficient functional tests to exercise approximately 60% of the source code.
• Standard code-coverage measurement tools will be used and results shared with the customer.

Production Ready

The initial goal of any migration project should be a new application that is functionally equivalent to the original one. The new application should work identically to the old one. Production Ready provides the greatest level of test coverage to ensure the functionality of new works like the old.

The Production Ready migration project includes:

1. Automated code migration
2. Additional automation mappings for high-frequency unmapped objects
3. Manual replacement of code where automation is not available or impossible
4. Full QA testing and bug fixing until all customer-defined functional tests pass
5. Knowledge transfer from our migration team to your engineering and maintenance team(s).

With Production Ready you get a compiling, running application that can be put into production immediately on your stack, private or public.

Engineering Services to Production

The most efficient and low-risk initial step for a modernization project is to create a faithful copy of the source application, but using modern programming languages and platforms. For some customers, this is a preferred outcome as it minimizes the disruption and confusion of the existing user base; others, however, would like to make some changes or improvements in their new application, such as:

• Adding functionality
• Refactoring code
• Building API endpoints
• Creating micro-services
• Re-creating or modernizing the look and feel

Our deep bench of engineers can help you with any of these or whatever you would like to do to your new application. You can focus your internal resources on higher-value projects while still getting the improvements you would like to see in your new/old application code. Post-migration, a team of experienced engineers and QA resources will modify the migrated application to fit your requirements.

To learn more, speak to your account manager.

Full Rewrite

Every engineering approach carries compromises, and automated migration is no exception. GAPMobilize offers services to rewrite your legacy application starting with a clean sheet of paper. Any modern architecture or programming language is available, based on your needs and desires. Our experienced team will work with you to define requirements, build out an architecture plan, and deliver code using current engineering practices including Agile and Scrum. GAP's intensive focus on QA includes eight critical components: 

• User Story (requirements) review to make sure acceptance criteria is clearly defined.
• Test plan development
• Test case development
• Developer unit testing
• Functional testing
• Code review, memory leak testing and application hardening   (performance in/out of background, in/out connectivity, etc.)
• Product owner acceptance testing
• Regression testing.

GAP's fully-baked approach to software development starts with their 2NABOX staffing: one resource in the US and one in LatAm to work hand in hand with your internal team and provide full transparency and visibility in the development project.  Ideally suited for organizations whose internal resources need to stay focused on the highest priority projects. 

Which is right for you?

It's no secret that developing software is hard, and estimating and managing large projects is fraught with risk of missing targets or outright failure. Mapping a course of modernization exposes you to a dizzying array of options touted by pundits, consultants, analysts, and maybe your crazy Uncle Eddie. 

I think it's safe to say we have more experience in this than anyone. Hopefully, with the right help, you won't end up like this guy:

^[1] You can't take a F35 fighter jet out for a test run either. Some things require training before use. Like chainsaws.

^[2] Borrowing from Winston Churchill