Migrating from Console Mode or Visual DataFlex Application to Today's DataFlex
What's involved, what tends to be the hard part, and what's worth weighing before you commit time and budget.
/*YES, YOU CAN GET THERE FROM HERE*/
Plenty of DataFlex shops still run applications that trace back to console mode, or to an early release of Visual DataFlex. These systems work — many have quietly run the business for twenty or thirty years. But at some point, people start ask whether it's time to bring the application forward.
This isn't a how-to guide. The goal is simpler: to give you the high-level view you'd want before deciding whether to take a migration project on at all — what's involved, what tends to be the hard part, and what's worth weighing before you commit time and budget. If you move forward and want more detail, our documentation, learning resources, and support and services teams are available.
Yes, You Can Get There From Here
The short answer to “can this even be done” is yes. Console mode and older Visual DataFlex applications can be brought forward to current DataFlex, and developers do it regularly, using migration tooling built for this purpose.
But “possible” and “quick” aren't the same thing. The honest answer to “what will this take” has less to do with your starting version than you might expect, and more to do with two other factors.
Two Things That Matter More Than Your Starting Version
How good is the existing code, structurally. Code that follows sound DataFlex conventions — business rules kept in Data Dictionaries, consistent structure, minimal reliance on undocumented workarounds — migrates far more predictably than code patched together for two decades. If your codebase has drifted from conventional architecture, that's the reality to budget for, not the version number on the box.
The size and shape of the application. This isn't only about lines of code. How many executables make it up? How many tables, indexes, and reports does it depend on? A single-purpose utility migrates very differently than a suite of a dozen interconnected programs sharing a database. Take an honest inventory before estimating anything.
If You're Starting From Console Mode
The first real decision — possibly the biggest one — is where you're headed: a Windows desktop application, or straight to the Web. Both are legitimate destinations, and reasonable developers land in different places. A few things worth weighing:
​
-
How your users actually work today. Console mode users often have a keyboard-driven, screen-by-screen way of working that maps more directly onto Windows than onto a browser. That doesn't rule out Web, but it's worth thinking through.
-
Your deployment reality. A Web target trades desktop installation and rollout for browser compatibility and hosting. That matters more if your users are widely distributed, or managing installs has become its own burden.
-
How much of the interaction model you want to preserve versus rethink. Windows can, in some cases, preserve more of the original screen flow. Web more often invites — and sometimes requires — rethinking how a screen works.
Beyond the platform decision, a few other things to expect:​
​
-
Not all your legacy code carries forward as-is. Some patterns don't have a direct Windows or Web equivalent. Business logic in Data Dictionaries tends to travel well; screen and interaction code is typically where the most rework happens.
-
A rewrite can sometimes be the more efficient path. For smaller or heavily dated applications, or ones already due for a redesign, building fresh in current DataFlex can beat migrating old code forward. Evaluate both paths honestly.
-
Your database is worth a look, even if it's not required. If the application still runs on the DataFlex embedded database, this is a natural point to consider SQL. Current DataFlex connects to SQL Server, MySQL, and other sources, and many developers find real benefits in backups, multi-user performance, and reporting once they switch. It isn't required, but it's a common companion decision.
​​
The pitfall developers mention most often is underestimating the interface rework. Console screens don't map one-to-one onto Windows or Web interfaces, and closing that gap usually drives more time and cost than the underlying business logic does.
If You're Starting From a Visual DataFlex Application
Because Visual DataFlex has gone through many revisions — grids replacing older list-style controls, 64-bit and Unicode support, tabbed interfaces, and more — the path forward from a genuinely old workspace usually runs through several intermediate versions rather than a single jump.​
​Expect to step through versions. The path from a genuinely old workspace usually runs through several intermediate releases - compiling and debugging at each stop - rather than a single jump.
Some version jumps bring bigger changes than others. The moves to Unicode and 64-bit compilation touch more of an application than a typical annual update, and are worth budgeting extra review time for. Grids replacing older list controls, and the shift to tabbed interfaces, are two other changes to expect along the way.
​
Database considerations apply here too. As with console mode, if the application is still on the embedded database, this is a natural moment to evaluate SQL.
​
Going straight to Web is an option, and FlexTron can ease the transition. A move to Web doesn't have to be an all-or-nothing rewrite. FlexTron lets you bring Web controls, and even entire Web applications, into an existing Windows shell — some teams use it as a bridge, modernizing a screen or module at a time.
​
Reporting deserves its own look. Whatever your reporting tool has been — DataFlex Reports, Crystal Reports, or something else — plan to revisit it, particularly if you're also changing your database.
Where the Time Actually Goes
Across both console mode and Visual DataFlex projects, the pattern is consistent: interface and interaction rework tends to take longer than the “plumbing” work of getting a workspace compiling on a current version. Weight your estimates accordingly.
A Few Common Questions
Do I have to migrate everything at once? No. Many teams migrate incrementally — module by module — particularly when using FlexTron as a bridge toward the Web.
​
Do I need to move off the embedded database to migrate? Not as a strict requirement, but it's common enough as a companion decision to be worth considering at the same time.
​
Is a rewrite ever the better answer than a migration? Sometimes — particularly for smaller or heavily dated applications, or ones already due for a redesign. Weigh it honestly rather than assuming one path is automatically right
Where to Go From Here
This article is meant to help you frame the decision, not make it for you. Every application is unique, and the honest answer depends on the specifics of your code, your database, and your users.
​
DataFlex's documentation and the DataFlex Learning Center are good next stops if you'd like to dig deeper. And if you're weighing whether to take a migration project on — or just want a second opinion before you start — our support and professional services teams are glad to talk it through.
Support Team Channels
It's old school, but it works!
Our support team is available during standard business hours to answer calls and emails.
​
We can often supply answers quickly and without much investigation. If it turns out that you need more in-depth assistance that will require significant time, an hourly fee may be applied.
Mon - Fri, 10am - 5pm US Eastern