I have about 2.5 years of professional sysadmin experience, including production environments, scripting, low-code automation, application maintenance, and some helpdesk work. Lately, I feel less challenged and want to move toward a DevOps or SRE position.
Most of my learning and experimentation happens in my homelab. I have used GitHub Actions and want to develop stronger skills with Terraform, Ansible, cloud platforms, and CI/CD pipelines. I have also started building a learning roadmap and was advised to document practical projects on GitHub.
What should I prioritize when making this transition? I would especially appreciate advice on which skills and tools matter most, how to build a portfolio that demonstrates real ability, common mistakes to avoid, and what has helped other sysadmins land their first DevOps role.
5 Answers
Look for opportunities to automate parts of your current job. User provisioning, workstation deployment, configuration management, monitoring, and repetitive maintenance tasks can all become useful automation projects. If possible, improve an existing deployment process or replace a collection of manual scripts with a safer, repeatable workflow. Real work experience is more valuable than simply completing tutorials.
You may already be closer to a DevOps role than the job title suggests. On your resume, translate your sysadmin work into outcomes: automated a manual process, reduced deployment time, improved reliability, standardized configuration, or supported production systems. Apply to roles that value infrastructure and automation even if they are not labeled strictly as junior DevOps. Your production experience is an advantage over candidates who only have homelab projects.
Your sysadmin background is already a strong foundation. Rather than learning tools separately, build a small end-to-end project that uses them together. For example, provision a cloud instance with Terraform, configure it with Ansible or Packer, deploy an application through GitHub Actions, and add a simple smoke test. That gives you something concrete to discuss in interviews and shows that you understand the workflow, not just the individual commands.
A low-cost cloud account is enough for experiments, but you can also do much of this locally with virtual machines or containers. The important part is having a working project and being able to explain the design choices.
A portfolio should show decisions and iteration, not just a list of technologies. Build one modest production-style application, provision its infrastructure as code, add CI/CD, include logging or monitoring, and document tradeoffs such as why you chose a simple virtual machine instead of Kubernetes. A repository that explains what broke, how you fixed it, and how you would improve it is much stronger than one that only follows a course.
Focus on the fundamentals first: Linux, networking, Git, scripting, Docker, and one cloud provider. Then deepen your CI/CD experience with projects that build, test, and deploy something real. Kubernetes, Helm, Terraform, and managed services such as EKS or ECR can come later; trying to learn every tool at once usually leads to shallow knowledge.
My current environment is mostly on-premises, and production deployments still rely on a Bash script I wrote. I’m considering using a cloud free tier or local lab to practice the same ideas in a more modern setup.