back to article That scary old system with 'do not touch' on it? Your boss very much wants you to touch it. Now what do you do?

Legacy systems have been sitting in server rooms for decades, gradually growing more complex in design, more expensive to operate, less understandable to administrators, and more indispensable to their owners. If some hero tries to poke around inside them, their face turns white when they realize the machines are running all …

Page:

  1. Giovani Tapini

    6 point plan?

    The very first thing you are given is a budget.

    The thinking comes later on...

    1. Anonymous Coward
      Anonymous Coward

      Re: 6 point plan?

      ...what's a budget?

      I support legacy systems where the only documentation is pretty much what I've produced, with no internal appetite for refactoring or replacing, but management definitely want to save DC space. Apparently I'll be becoming a magician soon.

      Or just finding a better job.

      Anon.

      1. Pete 2 Silver badge

        Re: 6 point plan?

        > ...what's a budget?

        It's a small bird that lives in a cage. In the past, they were used by coal-miners to warn of impending doom. When the budget stops and you still have work to do (or coal to dig), you know there is going to be trouble.

        1. deadlockvictim Silver badge

          Re: 6 point plan?

          You really are at the codeface there.

        2. Anonymous Coward
          Anonymous Coward

          Re: 6 point plan?

          >> ...what's a budget?

          >It's a small bird that lives in a cage. In the past, they were used by coal-miners to warn of impending >doom. When the budget stops and you still have work to do (or coal to dig), you know there is going to >be trouble.

          This is possibly the single best post, reply or comment I've ever seen in any kind of discussion about IT projects, management, planning, costs, budgets and what could 'possibly' go wrong...

      2. Hans Neeson-Bumpsadese Silver badge

        Re: 6 point plan?

        ...what's a budget?

        The best way to answer that question is to Explain it like this....

        Consider how long it will take you to analyse requirements for the job. Then consider how long it would take to design and implement a solution to meet those requirements. You should also think about how long it would take to design and develop a test plan to verify that the solution worked as expected. Now think about how long it would take to execute the solution and run all your test cases.

        Each resource - designers, developers, testers, etc. will each have a daily (or hourly) cost associated with them. Do some maths to work out how much it'll cost you for the resources to spend however much time you estimated. Then factor in a modest percentage uplift to cover risk mitigation, etc.

        Finally, think about the physical resources you will need to support your efforts - things like hardware, software, tools and the like - and work out how much it will cost to procure those.

        Add all of those together and you come up with a number....

        ...then knock a couple of zeroes off the end, and that will be the budget that you're given.

    2. Anonymous Coward
      Anonymous Coward

      Re: 6 point plan?

      Indeed. In my experience most of these old systems are still in place because there has never been budget to replace them.... Anon because I'm working in such a place now!

      1. Doctor Syntax Silver badge

        Re: 6 point plan?

        "In my experience most of these old systems are still in place because there has never been budget to replace them"

        And because they're what the business uses to earn its money.

        1. Mage Silver badge
          Devil

          Re: 6 point plan?

          Also outsourcing to a 3rd party modern equivalent of the old Timesharing services is a backward step. Is this an article selling AWS (=outsourcing to a 3rd party).

          People will regret outsourcing. Maybe not the Vulture Capitalists, but the customers and employees.

      2. jcitron

        Re: 6 point plan?

        That's what I ran into at a former company. Their legacy business system, not quite as old as some in the article but pretty old nonetheless, was in dire need of replacement in the late 2000s.

        The company never budgeted anything IT-related and had even let the support contract go on the software, let alone hardware. The system was kept running with tape, wire, and squirrels running in cages. I left before replacing anything and the last I heard they're still running this ca. 1998 HP Proliant 5000r server and scrounging on E-bay for hard disks.

        Oh well. That's their problem now and not mine. ;-)

    3. phuzz Silver badge
      Pirate

      Re: 6 point plan?

      It can help you get a migration budget if your legacy system starts to become less reliable. If it starts falling over every few weeks, (and only coming back up due to your heroic troubleshooting obviously), then you'll get some more leverage with manglement to ask for more money.

      Of course, I'm not suggesting you make it crash yourself, oh no! And I'm definitely no suggesting that occasionally 'bumping' the power supply, or 'snagging' the network cable would be the way to do it.

      Because a real BOFH doesn't need my suggestions ;)

    4. Tom 7 Silver badge

      Re: 6 point plan?

      A six point plan is one point short of being able to do anything about the problem at hand. I've found that point 7) Before you start get promoted to a level where you are actually allowed to actually see all the data you will be transferring.

      Nothing harder than trying to verify shifting data and associated semantics when you cannot verify that certain activities* are outside your purview.

      *when I say activities this includes fiddles that people quite high up never expected to be uncovered so an addendum to point 7 would be "I dont want the whole place to close down and all my friends to lose their jobs when most of the board are locked up so a decent reference and I'll be on my way if you dont clean up your act because the next one who tries to sort your IT may not be so generous.

  2. Joe W

    Insurers, banks, board of trade, government...

    ... all have "old iron" in the basement. Like: really ancient stuff, COBOL code, lots af assembler code. Lift and shift means that some company will charge you through the nose for an emulator of your old hardware (we are talking about hardware architecture form the 70s....). It also means that:

    - good luck finding the source code

    - that is documented

    - and actually produces the in-production machine code[*]

    Migrating and updating is (in my opinion, and from what I know from people working at such places) a long term project. Hire some intelligent young-ish people, pay them well enough so they do not look for greener pastures, and let them know that this is a project that can see them through retirement (and hope they stay with you!). Unfortunately the full benefits will only be known a decade down the line, which the higher echelons will not like: it has no tangible immediate benefit for the shareholder value, costs (now) only money, so it will decrease their fat bonus payments.

    If you want to speed things up: Be prepared to spend a f'ton of money.

    [*] apparently some developers used to fix the compiled machine code in production - so the source that is marked as the latest version is not what you have running...

    1. Paul Crawford Silver badge

      Re: Insurers, banks, board of trade, government...

      "actually produces the in-production machine code"

      Is a very valid point, and not just from the aspect of someone editing the machine code to fix a minor bug without facing hours of compilation time.

      You also have to deal with the problem that very likely what is archived was not the "last" version of what was compiled since not every project has good code management using CVS/SVN/GIT, etc and built-test cycles that are followed.

      In one rather sad case a programmer I knew died and several months later the company had wiped and re-used he PC. Then around a year later they realised the in-use executables were build using a version that had been on that PC but had not been checked in to the central repository. Had they only bought a new HDD for the machine...

      1. herman Silver badge

        Re: Insurers, banks, board of trade, government...

        "The programmer died..." That sounds like the Microsoft Windows USB Stack, which has 20 year old known bugs that will never be fixed, for that reason.

      2. Anonymous Coward
        Anonymous Coward

        Re: Insurers, banks, board of trade, government...

        "several months later the company had wiped and re-used the PC."

        ... well, that would be down to all these new-fangled "corporate procedures and quality standards" that just get in the way of real work!

      3. Anonymous Coward
        Anonymous Coward

        Re: Insurers, banks, board of trade, government...

        "In one rather sad case a programmer I knew died and several months later the company had wiped and re-used he PC. Then around a year later they realised the in-use executables were build using a version that had been on that PC but had not been checked in to the central repository. Had they only bought a new HDD for the machine..."

        All too common, this, all too common.

        Where I currently work, there's been a project to replace old IBM iSeries, still running part of the business. Given the profiles, here:

        - old beards with still access to the iSeries, never worked for another company, grumpy as fuck, not a word of english

        - manufacturing company

        - maturity in SW developpment = 0

        , I'm dead sure the sources for the running binaries don't exist elsewhere than a laptop ... somewhere. And even so, comments are surely in local, non english language. No way to re-compile anything. Project closed.

        1. mistersaxon

          Re: Insurers, banks, board of trade, government...

          If it's an iSeries there's a decent chance you could restore the lot to the latest version of the OS on new iron and it'll work perfectly. I mean if the company let the entire infrastructure stagnate for more than 20 years then issues will be more likely but otherwise... go for it.

    2. Anonymous Coward
      Anonymous Coward

      Re: Insurers, banks, board of trade, government...

      Interesting you describe COBOL as really ancient, I've heard people describe it as modern here

      1. Philip Hodges

        Re: Insurers, banks, board of trade, government... [COBOL is modernish]

        Some of us are as short in the tooth as COBOL, there's no need to be an insensitive clod.

      2. Michael Wojcik Silver badge

        Re: Insurers, banks, board of trade, government...

        Interesting you describe COBOL as really ancient, I've heard people describe it as modern here

        COBOL is ancient, as programming languages go; it's the third-oldest HLL, after FORTRAN1 and LISP. The language was developed in 1959, and the first working implementation appeared in 1960.

        There are modern COBOL dialects. ISO COBOL added OO support in 2002, following on from various proprietary OO extensions in the '90s. The latest ISO COBOL standard was published in 2014. Proprietary COBOL dialects have lots of the features typical of contemporary programming languages; Micro Focus managed COBOL, for example, supports anonymous methods, implicit typing, .NET extension methods, and so forth.

        In other words, it's both. The same can be said of Fortran and LISP variants (and even, to some extent, BASIC). When old programming languages persist, they do so in part by evolving.

        That said, a great deal of legacy COBOL applications use COBOL84 or older variants. I often see customer code that was originally written in the '70s or even '60s, and never updated.

        1Which is now "Fortran", of course, but since I'm writing about the original I'll keep the original capitalization.

    3. Anonymous Coward
      Anonymous Coward

      Re: Insurers, banks, board of trade, government...

      "- good luck finding the source code

      - that is documented

      - and actually produces the in-production machine code[*]"

      Exactly that. On most insurance/banks/manufacturers, back then, source mgmt was sci-fi concepts. All was in Joe Admin PC/workstation. Provided he did keep track of the latest. Never throw away a Joe Admin workstation, ever.

      The above is very often why lift and shift or emulation are preferred: you don't need to find out the source code that produced the production binary, if it even still exists !

      You run the black box on new or existing gear. VMware has long made a lot of money due to NT4.0 on ESX ...

    4. Doctor Syntax Silver badge

      Re: Insurers, banks, board of trade, government...

      "Unfortunately the full benefits will only be known a decade down the line, which the higher echelons will not like: it has no tangible immediate benefit for the shareholder value, costs (now) only money, so it will decrease their fat bonus payments."

      However, apply this to the TSB fiasco. What they thought was that running on the old Lloyds platform was costing them too much money and the dis-benefits of screwing up the migration became instantly well known.

    5. FozzyBear Silver badge

      Re: Insurers, banks, board of trade, government...

      Be prepared to spend a f'ton(*) of money.

      Would that be metric or imperial F'tons ?

      1. Alister Silver badge

        Re: Insurers, banks, board of trade, government...

        Would that be metric or imperial F'tons ?

        Well imperial, obviously, a metric one would be a F'tonne...

  3. Jonathan Richards 1
    Alert

    Time for buzzword bingo, sadly

    “In your greenfield you can introduce a microservice architecture so that the developers and new applications can use the latest technologies, build tools, frameworks, and methodologies to help the business innovate and adapt quickly.”

    ...said the expensive consultant, while the IT bods at the meeting detect a nauseating miasma, and the PHB at the head of the table nods wisely and wonders how small a service has to be, to become a microservice, and whether he has any already.

    Seriously, most businesses with such aged mission-critical legacy hardware and software aren't development shops. By definition they've survived this long well behind the curve, so that appealing to the boss's appetite for 'shiny newest and packed with buzzwords' may be profitable (for the implementation consultants) but runs big risks for the business. Find a solution that halves the distance between you and the bleeding edge, and there's a better chance of reasonable prices, available trained support, and not making your business dependent on some nine-days wonder.

    <img grumpygit.gif>

  4. ForthIsNotDead Silver badge
    Meh

    Cheaper?

    It's probably cheaper to introduce new hardware and software that produces the same *output* as the legacy system for the same input, but is, well, you know... new.

    This simply comes down pragmatic and skilful systems analysis, and careful counselling of the people that use the system day-to-day. Do not allow scope-creep under any circumstances.

    The new system will run side-by-side with the old system until all are sure that it is working properly. For example, when it produces end of month, end of quarter, and end of year accounts that all match the legacy system.

    It can be done. Just don't rush into it, don't through boat-loads of people at it. Start the project small and quietly, and up-staff when you are completely confident of what needs to be done.

    And finally, don't be tempted to throw shit loads of hardware at it. Consider this: If the system you are replacing runs just fine on a dusty old VAX, then it will probably run fine a modern PC. You will not need racks and racks of hardware. I've seen some things over the years are simply inexplicable. LAMP stacks and OOP have a lot to answer for!

    1. Dagg
      Facepalm

      Re: Cheaper?

      Do not allow scope-creep under any circumstances.

      Well that screws an agile approach....

      1. Ken 16 Silver badge
        Trollface

        you mean scope sprint

        If it's not defined, it can't creep.

    2. Michael Wojcik Silver badge

      Re: Cheaper?

      It's probably cheaper to introduce new hardware and software that produces the same *output* as the legacy system for the same input, but is, well, you know... new.

      This is wildly unlikely for the vast majority of non-trivial legacy systems. I suspect you have no idea what those systems do. They often implement hundreds of thousands of specialized, obscure business rules, many of which may not be documented anywhere else.

  5. Anonymous Coward
    Anonymous Coward

    I like the idea of a 'piracy' model for difficult migrations

    The 'piracy model' for IT migrations goes something along the lines of -

    1. What differentiates your business model to stop others from simply copying it?

    2. Where are the highest priority legacy (unsupported) systems containing your unique 'intellectual capital'? i.e. when you break it you lose business

    3. How hard is it to COPY the complete system, code and configuration from that old legacy system perhaps to a new emulated or virtual clone system? (emulators are available for many legacy systems and if it runs on commodity x86 kit then this is almost always the preferred option)

    4. How complex and time consuming do you estimate it may be to REDEVELOP and REPLACE the highest priority business functions from the same system?

    5. Choose wisely from option 3, 4 or NO GO before changing. moving and breaking anything!

    Unless your client is truly a unique leader in their area of business there is a reasonable chance that the competition already have an 'off-the-shelf' solution that may be used an an acceptable replacement for many key business application components. The problem is that if your business runs on nothing but easily replaceable systems and applications, it becomes very easy to clone your business and technical models and your only differentiators left are your people and working practices.

  6. Anonymous Coward
    Anonymous Coward

    One approach is to wait until someone introduces SAP into the organisation and then trap the SAP sales guy by suggesting that his system would not be able to replace legacy systems like the one in question. The legacy system then gets ripped out on the orders of the director who ordered SAP and the SAP implementation folk take all the work and flak that follows.

    1. Grikath Silver badge

      yeah... and you end up being the one having to live with the things SAP cannot do/accomplish, or which they claim can do , but only after [insert serious amount of dosh] for which there is no budget left, because SAP ate it all already.

      And don't forget, you're dealing with actual functionality that is gone, and will not be replaced...ever.

    2. FozzyBear Silver badge
      Alert

      Introduce SAP.

      I thought the gist of the article and commentary is trying to reduce the number of problems not multiple them!

      1. Anonymous Coward
        Anonymous Coward

        You know it makes sense !!!

        "Introduce SAP.

        I thought the gist of the article and commentary is trying to reduce the number of problems not multiple them!"

        You are forgetting that the 'Original Problem' was defined as a one of unknown difficulty and unknown achievability.

        If you 'Introduce SAP' the unknowns go away ........ you KNOW it WILL be Difficult, you KNOW it WILL never be finished to everyones satisfaction and you KNOW it WILL cost more than your Budget (or any Budget extension after that).

        Management do not like unknowns ..... so SAP wins !!! :) ;)

  7. Simon Harris Silver badge

    Front page picture

    Feeling nostalgic for the days when things were big enough to solder without needing a microscope.

    1. TRT Silver badge

      Re: Front page picture

      I've been blaming my failing eyesight on the progress of miniaturisation of components for years.

      1. jobst

        Re: Front page picture

        So your arms are not long enough, then?

  8. Pete 2 Silver badge

    Step 0

    > Before taking a pencil to the back of an envelope or breaking out the Excel and pivot tables, it’s important to understand who is driving the migration and what they want

    I would suggest that the very first step is to work out who will get the blame when it all goes terribly wrong (though I think we can all guess the answer).

    We learned how to migrate all the clockwork-powered computers prior to Y2K. The strategy hasn't changed just because the buzz-words in the sales brochure are different.

    The best tip is to employ outsiders to do the work for you. That way, when someone does go pointing fingers, it will be in the direction of people who no longer there (and therefore cannot deny their part in the failure: whether true or false). This is the major benefit of contracting-out work - the indemnity value.

    1. DCFusor Silver badge
      Happy

      Re: Step 0

      My kind of cynic, however, I laughed as I've had it go the other way.

      A company with similar issues hired my tiny outfit to do a similar set of things for what I suspect were a similar set of reasons.

      Long story short - we crushed it utterly, which resulted in long term follow on business, the firing of some of the employees who'd made it so hard for that customer in the first place, and we got to work in our own working conditions - no commute to the customer, at more than double the pay of the people we replaced, for a few years, doing everything else engineering that outfit needed.

      Wound up saving them money - and time - even though we cost a lot more per person, because we were, you know, actually good at this stuff, not sinecure hangers-on. Fond memories, those.

  9. Ken 16 Silver badge
    Holmes

    Retain, retire, rehost, replatform, refactor, and rearchitect

    Were all treatment strategies within Application Portfolio Assessment workflow long before AWS launched on the world.

  10. dajames Silver badge

    ... “six Rs” that ... remains (sic) useful when considering migrations. What are those Rs? Retain, retire, rehost, replatform, refactor, and rearchitect.

    What happened to Retest, or for that matter Redocument, and Retrain (assuming those things were ever done in the first place)?

    1. TRT Silver badge

      Put it all together...

      and it sounds like trying to start a Morris Minor on a cold and foggy morning.

      Rrr, rrr, rrr, rrr, rrr, rr..r....r......r........r...........rrr. Pft.

      1. Voyna i Mor Silver badge

        Re: Put it all together...

        "and it sounds like trying to start a Morris Minor on a cold and foggy morning."

        Excuse me.

        I used to look after my mother's Minor and it started without problems even in the depths of winter. You just needed to know how to adjust the SU, treat the distributor cap with WD-40 periodically and put in better cables to the plugs.

        I think you mean the Austin Allegro, widely referred to as the Agro.

        1. Peter Gathercole Silver badge

          Re: Put it all together...

          Worse than that, it was called the All-agro!

        2. Robert D Bank

          Re: Put it all together...

          from my neck of the woods Allegros were known as landcrabs. They were abominations, only surpassed by the Skoda 110's...shudder!

          1. TRT Silver badge

            Re: Put it all together...

            I think they got bad press... they gave us Hydragas suspension (yay!) and the Quartic wheel (boo!), and they had a reasonable 1.7L engine.

            I mean, it couldn't have been that bad... they went on for three whole series.

            Mind you... so did Derek.

            Yeah... scratch that idea.

            Awful car.

  11. potatohead

    'Migrate it to a cloud based micro-service based architecture'... right

    The thing about legacy systems is that they weren't originally legacy, they were the latest greatest architectural decisions running on cool cutting edge hardware. Now they just look like some weird mess of scripts and code running on an OS that none really understands, but they didn't start that way.

    I've a feeling that the average cloud based micro-service design will not look half as good as that weird legacy you are trying to replace in 5 years time, let along 20 years. Add a dose of vendor lock-in to a cloud supplier, and you'll have management screaming at the next team to replace their new legacy system. 'Ah, this is a cloud v1 system - you need a cloud v2 architecture'. Rinse and repeat.

    1. Ken 16 Silver badge
      Trollface

      versioning

      5 years out you'll just need to test that version 68.4 of micro-service CheeseServer is compatible with versions 80.9 through 94.5 of WidgetDispenser, version 3 of UserLogin (they're afraid to mess with that one much in case it breaks) and v32 of bought in micro-service framework apps. The good news is that there's a AI salesman in the board room selling you a machine learning test suite.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019