The Packager’s Role in Enterprise Software Deployment
It's 2012. I’ve just finished getting my IT bachelor’s degree, and I was eager to hop on an exciting opportunity.
A paid academy with the promise of a future job as Software Packager in an enterprise environment, as I preferred corporate and enterprise infrastructures to programming.
The role description sounded something like this:
“Prepare and customize applications ready to be delivered to the users.”
A normal workflow would go something like this:
1. Ticketing System assignment
An application package request is received in the software packaging team queue. This request normally includes an application owner as a contact person and an order document (a file containing specific install instructions and customizations to be done).
2. Discovery phase
The packager reads the Order document attached to the request, gets the installation source files, and begins validating information.
He then takes the source files, fires up a virtual machine containing a corporate OS image, and starts installing the application while checking if information from the order document matches.
If everything checks out and no clarification is needed, the packager proceeds to the next step. Otherwise, he needs to contact the application owner for information.
Examples of situations include an extra step in the install process with options such as “Select which features to be installed” that are not present in the order document.
3. Packaging phase
The packager prepares the package depending on the setup type and requirements. For example:
- Finds all the silent install switches
- Detects system modifications that require customisations using tools such as Process Monitor
- If the setup is EXE, the changes are implemented using a script
- Prepares an MST using tools like ORCA or Advanced Installer, which should be called with the original MSI file
- If the application is an exe and does not support silent install parameters, use tools like Advanced Repackager to completely repackage it
4. Internal Testing
After the package has been created, it is tested internally on another machine, preferably by another dedicated tester from the team.
After the tests are completed successfully, the packager prepares the package in the form of a structured folder, including the necessary scripts, sources, MSTs, and a document containing the install and uninstall instructions.
This is then delivered to an integration team, who upload the package into configuration management tools such as SCCM and Intune before deploying it to end users.
The packager closes the ticket. His job is finished here.
As you can see, the Packager plays no role in the client-side integration, deployment, rollout, or monitoring process. He would only intervene if any issues or misconfigurations occurred for end users after the package was installed.
As complex as I believed my work was back then (because indeed there were many customizations for each application depending on the client), I always felt like I was only doing a small piece of the puzzle.
Internal Packager 
As years passed, I was offered a job position as a Software Packager, but this time it was internal.
I was doing the software packaging only for the company and not for other customers (outsourcing), as I had done previously.
I immediately noticed the job role was different:
- Prepare application package
- Upload package in configuration management tool
- Rollout to end users
- Troubleshoot installation
- Maintain updates for core applications
- Maintain OS image
- Offer application support
Since there was only one client, the level of application customizations was basic:
- Silent install
- No auto-updates (for admin control)
Only occasionally were special applications requested that required customizations.
Present-day software packager role and requirements
If you look on platforms like LinkedIn or other online job markets, you will rarely see a “pure” Software Packager job title listed.
More often you will find something like an Infrastructure Technical Engineer or Endpoint Management Specialist.
Even if you do find a Software Packager job title, it will undoubtedly include responsibilities such as:
- Software deployment
- Device management
- Powershell scripting
- Windows OS troubleshooting
- Azure AD
Some of the reasons are the following:
- Pure software packaging is a niche job
- A pure packager, once he masters the job, unless he wants a challenge, will rarely change his job or career path
- Old-school software packaging is no longer practiced. There is no need for such extensive customizations to make applications “enterprise accepted”. Vendors have learned, and most of them provide different installers with precustomizations already done for enterprises
My Final Thoughts
Software packaging has changed over the years. And that is understandable considering everything around it has evolved as well: from on-premises infrastructures with large servers to cloud environments, from legacy applications to modern formats like click-to-run and MSIX, and applications that are enterprise-ready rather than just home-user oriented.
Personally, this does not scare me. I was always the type of person who wanted to go beyond his scope. I was always interested in connecting my work with others in the end-to-end process, even if it was scary and sometimes out of my comfort zone.
There is always fear of the unknown. But remember, we’re talking about IT, and things change fast. Learning is the only way to keep up with what’s next.
Don’t get fooled by the saying “A master of all is a master of none”. That’s only the first part of the quote. People ignore what follows: “but oftentimes better than a master of one.”
Written by
Radu Popescu
Technical Writer at Advanced Installer, Technical Engineer on various enterprise client projects. Experienced in Software Packaging, SCCM infrastructure and System Administrating. Tech enthusiast and music producer in his spare time.