More than 95% of Fortune 1000 companies still use IMS, IBM\u2019s ancient hierarchical DBMS. At least, that\u2019s the number according to TwoBitHistory.org.\n\nMy own informal survey, in contrast, reveals that approximately zero percent of the best IT developers have any interest in working in that environment.\n\nThe ability to attract top talent is one reason \u2014 not the only one but among the most important \u2014 for CIOs to modernize their applications portfolio. Others include reduced license and support fees, and improved flexibility and adaptability.\n\nExcept that \u201cmodernization\u201d isn\u2019t as straightforward a proposition as it might seem. It has dark secrets that smart CIOs must take into account in their decision-making.\n\n1. Application modernization is a compound issue\n\nApplication modernization (\u201capp mod\u201d if you\u2019re a member of the Cool Kids Club) covers a bunch of very different solutions to a bunch of very different problems.\n\nDepending on the application and who you talk to, app mod might mean version updating, replatforming, platform replacement, language modernization, refactoring, or COTS conversion. While they\u2019re all called \u201cmodernization\u201d they have little or nothing in common. Each has pitfalls to be aware of. Some are well-known; others are more covert.\n\nPlus, the fact that modernization means so many different things is in itself particularly vexing: Before you can modernize a given application you first have to decide, not only whether to modernize it, but which type of modernization it needs.\n\nThen multiply by the number of applications in your portfolio.\n\n2. Version updating is its own form of debt\n\nSome IT leadership teams think they\u2019re being business savvy by \u201cnot buying technology for technology\u2019s sake,\u201d and, to pile one clich\u00e9 on top of another, taking an \u201cif it ain\u2019t broke, don\u2019t fix it\u201d approach to managing applications and the stacks they run on.\n\nThey apply this logic to commercial applications, and to every platform every application runs on \u2014 the server OS, DBMS, CMS, development environment, desktop OS, browser, and on and on \u2014 updating only when specific new features deliver a specific new ROI.\n\nUnfortunately, the Law of Pay-It-Now or Pay-It-Later still holds sway: Pay-It-Later invariably costs more and is more disruptive than staying current.\n\n3. Replatforming solves for only one variable\n\nMoving legacy applications to an open environment that has corresponding platforms all the way down the stack is another popular modernization approach \u2014 with a not-so-secret gotcha. Replatforming means migrating from mainframe-hosted z\/OS + COBOL + CICS + DB2 to x85-hosted Linux + COBOL + CICS + DB2, for example. In cloud migrations, this is called \u201clift-and-shift.\u201d\n\nHere\u2019s what you get: reduced license and vendor support fees. The dark secret? That\u2019s all you get.\n\n4. Platform replacement costs more\n\nPlatform replacement is a modernization method that changes out just one platform an application runs on, on the grounds that it\u2019s obsolete or losing market share and mindshare. You might, for example, switch an application\u2019s DBMS from Sybase to SQL Server. While this is also sometimes called \u201creplatforming,\u201d it has nothing in common with replatforming as described above.\n\nWhat you get: fewer of the risks and vulnerabilities that come from using obsolete technology; also, access to a better pool of talent. What you don\u2019t get: Reduced costs or any improved capabilities. Costs will, in fact, increase because you\u2019ll have to license the replacement platform.\n\n5. Language modernization often makes a bad situation worse\n\nThe seductive sales pitch says automated tools will extract your business logic from your legacy COBOL code and rewrite it in a modern language. This is often accomplished by replacing, say, a 100,000-line-of-code COBOL application with a 100,000-line-of-code Java application.\n\nThat\u2019s the darkest secret of language modernization: Languages aren\u2019t just vocabulary and syntax. Languages bring with them application design philosophies.\n\nThe second-darkest secret: Languages generally bring with them whole libraries of pre-developed logic as well. A development team writing a new application takes advantage of these libraries. Few if any code converters can do that, which means the converted code they generate is even harder to maintain.\n\n6. Refactoring truly modernizes. So of course it\u2019s costly and time-consuming\n\nRefactoring is a modernization technique that converts an obsolete application\u2019s structure to conform to proven practices \u2014 normalizing data, for example, or restructuring monolithic code to a microservices architecture.\n\nSome tools purport to automate much of this restructuring. By all means, try them \u2026 on the vendor\u2019s nickel until a few well-chosen proofs of concept convince you the tools work as advertised.\n\nAlso beware: Some versions of automated refactoring preserve the application\u2019s behavior exactly. While this does minimize business disruption, it doesn\u2019t convert an overnight-batch application to near-real-time processing \u2014 the architectural change most likely to drive competitive advantage.\n\nRefactoring delivers serious business benefit in the form of improved adaptability and flexibility. But there\u2019s no such thing as a free lunch. In the case of refactoring there isn\u2019t even such a thing as a McDonald\u2019s-budget lunch. Architecture modernization delivers the goods, but it\u2019s expensive and effort-intensive.\n\n7. COTS conversion might not sound like a modernization technique \u2026 but it is, and is often the best modernization alternative\n\nOften, the best path to a modernized application portfolio is to replace a current-state application \u201cecosystem\u201d with a modern suite of applications written by someone else. It\u2019s far from a panacea \u2014 anyone who\u2019s ever been involved in converting to a COTS\/SaaS suite knows how difficult it can be \u2014 but it\u2019s often the least risky and cleanest way to replace a collection of applications whose platforms and architecture are yesterday\u2019s news to something that has a future and can help the business attain its planned future.\n\n8. Knowing what you have takes more perspiration than automation\n\nNow that we\u2019ve run down the dark secrets of your various modernization methods of choice, there\u2019s something more fundamental to beware of. Before you can modernize an application you need to know you have it and how it\u2019s built so you know which of the modernization types just discussed might be applicable.\n\nSadly, despite all the brilliant promises made by all the brilliant purveyors of brilliant automated discovery tools, these tools are only useful for discovering servers, not what applications run on them.\n\nWhat makes the lights grow even dimmer is that if your application inventory documentation is so incomplete that you need auto-discovery, it\u2019s incomplete enough that you haven\u2019t documented the platforms \u2014 the development environment, server OS, DBMS, content management system, and other tools \u2014 on which each application runs. Until you know this you can\u2019t begin to choose which of the modernizations discussed above will provide the most benefit.\n\n9. Software is an opinion \u2014 which makes application integration an argument\n\nEach business application encodes a development team\u2019s opinion as to how some aspect of the organization should run. Its opinion\u2019s syntax is scribed in code. Its vocabulary is chiseled into the application\u2019s data design.\n\nWhere the scope of two or more applications overlap \u2014 when, to take a simple example, the accounts receivable and CRM systems both maintain customer data \u2014 automation is needed to keep the two sets of records in sync. Add up all of the application overlaps in a portfolio and the result can be hundreds of custom point-to-point interface programs, all of which need to be modified and regression-tested every time a development team adds or alters an application.\n\nAn enterprise service bus (ESB) or similar technology can help reduce the sheer number of interfaces defining a single interface for each application.\n\nBut in addition to the sheer number of interfaces there\u2019s the problem of semantic misalignments \u2014 that is, your accounts receivable and CRM systems\u2019 customer data models differ. Reconciling these different definitions of the same entity is what makes integration tricky at the start and trickier to maintain.\n\nAn ESB can\u2019t fix the problem of differing semantics because the problem isn\u2019t technological in the first place. It\u2019s that the developers disagree.\n\n10. Modernizing the IT workforce is often harder than modernizing the applications they support\n\nYour workforce is, presumably, highly competent at maintaining and enhancing the applications and underlying platforms that comprise your current applications architecture. They\u2019re also a repository of deep knowledge about how their applications are used to make the business run as it\u2019s supposed to run.\n\nThey aren\u2019t highly competent in the replacement applications and platforms your modernization plan will implement.\n\nYou\u2019ll need them to become just as competent in the replacements as they are right now if your modernization plan is going to work.\n\nBeyond that, you\u2019ll need them to become competent so they\u2019re able to spot the opportunities for business improvement that can only come from smart people who are familiar with both the available tools and the current situation.\n\nThe dark secret: Showing them the door and hiring replacements instead just doesn\u2019t work.\n\nSure, you can terminate them. But finding competent replacements will be neither cheap nor easy, and no matter how competent their replacements turn out to be, the rule of thumb is that replacing an employee costs the equivalent of a year\u2019s salary \u2014 it would be prohibitively expensive.\n\nWhich is one more reason the last app mod dark secret is the worst dark secret \u2026\n\n11. Well-run IT organizations rarely need to modernize\n\nWell-run IT organizations practice lifecycle management. They keep everything current all the time. This keeps the budget manageable \u2014 the app mod effort is steady with few \u201cbig bang\u201d initiatives, and has the happy fringe benefit of keeping your workforce modernized along with your applications and platforms.