Skip to end of metadata
Go to start of metadata


A web content management system (webCMS or WCMS) is a software system that provides website authoring, collaboration, and administration tools designed to allow non-technical users, with little knowledge of web programming languages or markup languages, to create and manage website content with relative ease. A robust webCMS provides the foundation for web site development, offering users the ability to manage documents and output for multiple author editing and participation. Most systems use a separate database to store page content, metadata, and other information assets that might be needed presented within the website. Development and administration is typically done through browser-based interfaces, but some systems require the use of a "fat client" installed locally on the administrator's computer.


PO: Som Seng
TO: Phil Saulnier
SM: Jennifer Hernandez

Users: UMassOnline MarketingUsers: Campus Marketing (ex. Amy Yacus)
Users: Campus Tech (GoLive)
Users: UMassOnline Tech Admin


Our current Web Content Management System, Drupal, replaced our previous home-grown custom tool that was developed in 2001 (see QA LMS Login Pages) and has evolved over the past several months into: a webCMS, for developing and managing web pages within the domain; a basic CRM, capturing student lead information, and; a reporting tool providing web/user analytics. Drupal has been customized to meet the needs of UMassOnline's Marketing team, and has worked well for the past several months.


Currently the Web Content Management System is used in the following ways:

  • Student/Faculty log in for Blackboard Vista
  • Program Listings (date, location, cost)
  • Course Offerings (date, location, cost)
  • Marketing of materials/services offered
  • Showcase of Blog post/upcoming events
  • Allows prospective students to communicate with Program Directors
  • Technical Support Portal
  • Links out to campuses (link sharing)


The current community who administer the Web Content Management System (Drupal and QA LMS Login Pages) includes the following:

  • UMassOnline Marketing Team (Site Administrators)
  • UMassOnline Technology Team (Log in page management, Announcements, Some technical support)
  • End users/prospective students (searching for new courses/programs)
  • Current Students (searching for new courses/programs)

System/Technology Platform

Web Content Management is currently provided through Drupal.

Login Pages for the 5 UMass campuses is currently managed using QA Login Pages.


Drupal, as an open source platform, is license free.

"QA" is a custom built webCMS build using Coldfusion. Licensing for Coldfusion is through...



Support of the QA system (Login Pages) is provided via JIRA.


Support for Drupal (Web Content Management System) is provided through JIRA.


While no formalized training exists, there is a cornucopia of information available online. For UMassOnline specific installation of Drupal, local documentation is maintained here.

Current Issues

Current Status


  1. Where does this project currently stand? We would like to being the process of moving this forward but need to understand where we are from a business perspective before we move along. 

    1. All,

      A few issues...

      Technical: UITS came to UMOL to ask if we could move QA (CMS/CRM) out of the 474 Main street data center. This request coincided with UMOL's Biz Dev's desire to extend functionality of the CRM, ensure greater stability, and reduce risk for an unsupported platform. Unknown to UITS at the time the UMOL tech team had begun exploring CMS options that provided the current functionality of the web content management features of "QA" (a dollar for anyone who can tell me why it is called QA.) In addition, the UMOL Biz Dev staff were also looking at a solution extending the CRM functionality.

      With this request from UITS, UMOL increased our efforts to identify a web CMS solution and settled on a recommendation of Drupal (see above for rationale). In order to get started the UMOL Tech Team began testing the system on a local system within the UMOP LAN and requested a dev environment be set up for expanded technical and functional development/assessment. As the content and functionality was developed and/or migrated from the existing QA system this dev environment would transition to the production environment. Existing CRM functionality would be integrated, yet still hosted at 474 Main until a solution was identified by UMOL BizDev and integrated per their specifications.

      To date UITS has not made such an environment available to UMOL, nor has a CRM been selected by Biz Dev (although the latter should not intefer with the web-CMS implementation). In order to avoid continued delays, specific to migrating the web CMS, I have reached out to a third party service for an estimate to accommodate our needs with hosting and support of Drupal (or any other solution). With an estimate in hand, we are "technically" ready to move forward with the web CMS migration.

      Financial: There will be costs associated with hosting outside of UITS. I am assuming and have been led to believe, the costs for hosting at 474 are equal to, or even less, than hosting at Shrewsbury. In addition, there will be costs for migration and development (either for continued work from Dina Kovar, if applicable, or another service for Drupal specific skills unavailable in UITS or UMOL). In addition, while not part of the Tech Team's budget, the CRM licensing, hosting and integration work, I suspect, will need to be considered. As there are current budgetary concerns (due to reduced enrollment rates, growing costs for existing services, alignment with campus expectations), I have not heard if the appropriate/expected financial analysis has been undertaken (e.g. how is UMOL recovering costs for this implementation?).

      Operational: Looking at roles and responsibilities, one option is to continue to work with Dina Kovar to ensure functional and operational parity between the legacy QA system and the new web CMS/CRM platform. I have had several conversations with Dina and feel she could provide support in identifying information architecture (how information is collected, stored, shared) and functional/operation requirements (how users interact with the system to achieve specific goals). In addition, as we expect to continue use of the legacy CRM until and new system is identified, Dina can play an important role in the integration between these two systems where/if needed. However as UMOL is not yet able to move on the CMS or CRM development, such services are not needed. I expect Dina's services are still of value to ensure continued access and performance of the QA system--although the UMOL Tech Team plays no role in those activities as these are managed technically by UITS and operationally by the UMOL BizDev team.

      Conclusion: In order for UMOL to move forward with a web CMS implementation we must identify a hosting and support service (UITS or other). In order for us to identify a hosting/support solution, UMassOnline must resolve the open financial issues. Until then, the only option is continue with the existing service and service levels (which are not satisfactory for either QA features, stability or performance).

      I don't think this is where the Biz Dev group wants to be, but the Tech Team is ready to move as soon as these issues are resolved.

      1. There seems to much confusion over the status of both the CMS and the roles of folks involved based on the emails I have received. I think if one reads the above they should understand, at least, my perspective. I have shared the above with everyone so that we can begin to align ourselves and will address questions/concerns I have received in emails here so that we do not suffer from information silos.

        Regarding the development requirements and Dina Kovar's role specific to the CRM, I would like to "clarify, and confirm, what projects I want her to work on, how much time I expect them to take in terms of hours, and what the timeline is for completion. Importantly providing any qualified response to these questions would be based on conditions that I alone do not control (again please see the comment above). I will try to explain in greater detail.

        1. The UMOL Tech Team has recommended Drupal for the CMS after conducting an evaluation based on current functionality in QA.
        2. Support/Development considerations, roles and responsibilities:
          • I do not know how much experience Dina Kovar (or any of us in UMOL/UITS) has with Drupal or the underlying technologies that support it, therefore I am not sure what role Dina Kovar or the Tech Team can play in "development."
            • "Development" to me means, software development, i.e. customizing/extending the native functionality of the application (i.e. Drupal) to provide new or extended features. I do not foresee us actually undertaking any "development" as it may not be technically required (Drupal provides a very robust set of features natively) and I do not think we want to invest in custom work that may put us in a similar situation like we find ourselves now, too far away from the native product.
          • I do not know how much experience Dina Kovar or UITS/UMOL staff have with Drupal "administration."
            • Application administration to me, includes configuring and managing the application using the native tools set available though the native administrative/back-end interfaces of the software. In addition, we have already tasked Kevin O'Brien with this role, as he does for other internal systems such as Confluence. Considering this will be a long-term internal service, we should have internal staff to support it. UMOL will invest in Kevin's professional development to fulfill this need.
          • I do not know what Dina Kovar, UMOL or UITS can play, or what we will need for "systems administration."
            • "Systems administration" to me means keeping the environment, in this case a LAMP stack, up and running to support the application. I expect this will be done by the staff of our service provider.
            • The actual service provider we will use to host the CMS is unclear. As I mentioned in the above link, I have asked UITS to set up an environment for us for the CMS (despite the actual product of choice) and they have not provided us with this. If they did, I would expect UITS staff to manage that environment. Due to the lack of response from UITS, I have reached out to a 3rd party service provider for hosting information. If we do go with an external provider I would expect them to manage their environment.
        3. We will need to migrate both the functionality and content. Migration Considerations:
          • Despite the platform for the CMS selected (i.e. Drupal or something else) we will need to migrate the content of the old site to the new site. This would require a "content manager."
            • A content manager in my mind would be responsible for replicating the existing text, graphics, media, etc. from the legacy system to the new CMS. This may also include edits/updates/enhancements to the content. I would think one of the Biz Dev staff would want to either do this, or direct this activity. This is not a technical role and I would not expect the Tech Team to undertake this. The Biz Dev staff may have identified Dina Kovar for such a role.
            • In addition, to complete the migration the user experience (UX) would need to be replicated. By this I mean we would need to ensure the site's information and organizational structure/architecture (i.e. page hierarchies, relative links, etc.) is consistent with what is current provided. Again this may be something Biz Dev wants to do or wants to manage and they may have selected Dina Kovar or another person for this role: again this is not a technical role.
            • Finally, regarding migration, we will need to replicate the user interface (UI). Here I would expect a technical resource to play a significant role in both developing the page layouts in line with the content manager and UX designs/ideas/goals (e.g. templates) as well as provide the web interface for any services or integrations used within the site (e.g. forms, CGI, queries, dynamic pages, etc.). Many of these may be done (in order of preference) through native web CMS functionality, the integration of new web CMS modules, developing specific middleware for integration, or customizing/developing specific new modules for the web CMS.
              • Depending on how the legacy system's functionality maps to the new system, I do see a role for Dina Kovar here, as mentioned in the comments above "identifying information architecture (how information is collected, stored, shared) and functional/operation requirements (how users interact with the system to achieve specific goals)." I simply do not know at this time what those integration points will be, how complex they are, what approach would be best, what skills are required to achieve them, or the time frame for their development.
        4. Ongoing support for the current QA environment.
          • As mentioned above, because we are still operationally dependent on both the web CMS and CRM functionality of "QA", UMOL and UITS will need ongoing support for that system in case an issue arises.
            • As the UMOL Tech Team does not support this application in any way, either at the application or systems level, I would hope the UMOL Biz Dev group and UITS have made arrangements for ongoing support and would recommend they continue working with Dina Kovar.

        Based on this, I cannot yet provide any detail as to the needs for implementation (standing up the CMS, migrating the content/features/functionality and integrating it with external services), and thus the skill sets or schedules, and therefore who will undertake which roles. My recommendation would be to develop a product backlog representing each of these tasks (the features/functionality deemed important by the Biz Dev Staff). then prioritize those. Once these are available we can determine what level of complexity, technology, skill and ultimately who can undertake these tasks. Then with this, I will be able to provide Dina Kovar with more details about her long term role.

        My inability to define Dina Kovar's technical role, should not deter the Biz Dev group from contracting with Dina to assist in the development of the product backlog and I would recommend that she do so.