Patch Management Strategies?

Sort:
You are not authorized to post a reply.
Author
Messages
whsmacon
Basic Member
Posts: 6
Basic Member

    We're new to Lawson (went live 3 months ago) and are trying to formalize a patch management process. Right now, we're basically applying CTPs to fix errors as fast as we can when users bring them to our attention, testing (minimal) and then pushing them to production. We keep a spreadsheet with patch/reason/env/date ... What are most people doing as far as timing/testing/documentation? Is there a 'best practice' for patch management in a Lawson environment? Any help would be appreciated!

     

    Thanks,

    Walter

    TJ Mann
    Veteran Member
    Posts: 44
    Veteran Member
      apply patch to fix your current issues only, not to get latest and greatest.

      for ESP and MSP, try to stay one version behind Lawson GA. good luck.
      Leonard Courchaine
      Veteran Member
      Posts: 55
      Veteran Member
        Hello Walter,
        We've been on Lawson for a very long time here at Children's Healthcare of Atlanta and have a pretty formal patch management process that goes approximately like this:
        - We have what we call Maintenance Cycles approximately 3 times a year (it was 4 times a year up until last year). These formal, planned maintenance cycles include environment patches so that we stay fairly current on the environment patches along with application patches (CTP's) requested by functional groups. Note: We'll **never** install the latest/greatest environment level patches but will only install ones that have been out there for a little while. We've been burned way too much lately by trying to stay up to date. All Infor's focus appears to be on new stuff they're trying tp sell and not so much with current things we're using. (Incredibly frustrating!!) For 2015 we only have two maintenance cycles because we're upgrading to v10 in July.
        - Between these Maintenance Cycles, we only do patching (mostly CTP's) if/when an urgent issue arises and there's a known fix/CTP.
        - We also have other important, ancillary things built into our Technical Maintenance Calendar, e.g. LBI updates, RQC updates, MSCM updates, Oracle/Unix security patches, system restarts, etc.,.

        Again, due to Infor's focus on new stuff, (and not 9.0.1 which is where we are still), we've even backed off trying to be more proactive with CTP's. For example, up to last year, the functional areas would give us lists of CTP's they wanted, based on simply going out and proactively searching for CTP's for programs we use here. We've (and others I hear) have determined that applying CTP's "just because" is not a good reason and, again, can break more than it fixes!!

        A typical maintenance cycle for us is made up of the following:
        - Functional areas provide list of requested patches - 15 days Mon 02/23/15 Fri 03/13/15
        - Load into DEV/TEST environments - 10 days Mon 03/16/15 Fri 03/27/15
        - User Testing - 15 days Mon 03/30/15 Fri 04/17/15
        - Load into PROD environment 1 day Sat 04/18/15 Sat 04/18/15
        We publish our maintenance calendar at the beginning of each year and distribute it and attempt to keep it updated.
        Let me know if you'd like me to send you a sample of what we call our Technical Maintenance Calendar. (leonard.courchaine@choa.org)
        Hope this helps somewhat as you folks come up with your own strategy.
        Let me know if you have other questions.
        Lenny
        leonard.courchaine@choa.org
        Carl.Seay
        Veteran Member
        Posts: 109
        Veteran Member
          Ideally, all application issues would be flushed in a Test environment, so you're not applying CTP's in Production on a regular basis.

          Every 6-12 months, evaluate the latest releases and release notes, and decide (or have your users decide) which to update. Try to keep everything up to date: LSF (ESP), Applications (MSP), Landmark, Landmark Applications, LBI, MSCM, etc. It's much more manageable if you update on a regular basis. It can become a nightmare if you get too far behind. I also agree with TJ on n-1 strategy. Developing a written policy could help.

          I would recommend applying all LSFCT patches available when doing an ESP update. Applying all CTP's (included in MSP above yours) is great too, if you don't mind downloading 500 individual patches. Of course, you're just as likely to have a bad version as if you don't apply all CTP's.

          Best of luck to you!
          Massimo Emilione
          Advanced Member
          Posts: 29
          Advanced Member
            As everyone has stated you do not want to put every patch you need into production right away. You do want to have a test system to validate the changes wont have any negative impact asthere will be times when patches may break other things. Most customers tend to pile up their patches and do them either 1x or 2x a year. The latest trend is that most are performing a major update like a MSP & ESP upgrade 1x a year and then applying year end patches with minor CTPs alongside. The reason for this approach is that many customers have found during integrated testing a patch for one area will break another area's application and more testing should have been done to get a complete picture of what to expect from the patch, but getting everyone's time at the same time is always difficult.

            Here at Avaap we actually created a tool to automate testing because of those concerns from our customers. With our tool our customers are able to reduce the amount of time required to test, see exactly what was test and allow for more patches to occur. You can view our latest demo here http://www.avaap.com/events/webinars/. We have customer case studies available here http://www.avaap.com/products/test-automation/

            Let me know if you need any add'l info.
            Jwiff
            Basic Member
            Posts: 12
            Basic Member

              First: Welcome & Good Luck!

              Our Background:

              We are on 9.0.1; using only HR, Payroll, and EMSS; have used Lawson since the '90s. 

              We have HEAVILY modified many programs, thus applying CTPs mean: Update on our test env; re-apply our mods (if not incorporated in the new changes); activate; test - then promote to UAT & Prod envs. -- applying to UAT is done as soon as we can schedule it after cursorily testing on test, then we wait 1 month for Prod.

              Maintenance Strategy:

              CTPs - ONLY as needed (generally, this means tax or Affordable Care / Benefits changes). -  we maintain a spreadsheet as you described.

              Every 3 - 4 years we do a 'big bang' - new hardware, OS, ESP (or full version), and MSP -- we try to avoid doing Oracle upgrade at the same time - I'm not sure we will have that luxury when we go to v10 in 2016.

              Other ESPs only if mandated for technology (IE11 support was our last driver).

              A word of warning: Don't modify - it will save you years of work.

              You are not authorized to post a reply.