How an HR multinational's IT team retired its custom redirect scripts and forgot about certificate management
Samuele Citterio | IT Network Manager at Gi Group Holding
Four hundred domains, two engineers, and a TLD-redirect problem most IT shops accept as background noise
Gi Group Holding is an Italian-headquartered HR and staffing multinational with offices in roughly thirty-five countries and five main commercial brands, plus a long tail of sub-brands acquired or built over the years. Multiply five brands by thirty-five countries and you get a domain portfolio that runs into the hundreds. The number Samuele Citterio puts on it is four hundred TLD variants in total, owned and managed centrally by IT.
Most of those domains do not carry primary websites. They redirect. Some send visitors of a discontinued brand to the brand that absorbed it. Some send country variants to the regional flagship. Some are mnemonic shortcuts left over from campaigns that ran years ago and still receive enough traffic that breaking them would generate complaints. None of these redirects is individually critical. Collectively, they are the connective tissue of a multinational web presence, and they need to work.
Inside Gi Group, that work sits with Samuele and one colleague. Two people, an IT Network Manager who has been in the role for fifteen years and a junior who joined recently. Domain management, DNS, redirects and certificates land on that desk.
Why a custom redirect setup quietly stops being good enough
For years, the redirects ran on a custom internal solution. Web services configured to do the 301 forwarding through regex rules. It worked in the sense that traffic arrived where it needed to arrive, but only on HTTP. When a user explicitly typed the HTTPS prefix, the certificate did not match and the browser threw a warning. Three or four years ago, when HTTPS-by-default became the assumption rather than the exception, that gap started to show up in real life.
The signal did not come from an audit or an incident review. It came from the marketing teams, country by country, who would pinpoint a certificate error on a legacy domain right before a campaign went live. Samuele's team would fix the specific case, but the underlying setup did not change. Building a proper certificate lifecycle into the existing solution meant scripts that handled Let's Encrypt or commercial issuance, automated renewal, error handling for the renewals that quietly fail. For a portfolio with four hundred TLD variants distributed across five brands and thirty-five countries, that was a non-trivial engineering project layered on top of the day job.
And every new redirect, before redirect.pizza, took roughly twenty minutes of Samuele's time to configure end to end. Twenty minutes feels small in isolation. Multiply by twenty redirects for a brand rebranding project and you have most of a working day spent on a problem that, by his own description, was not particularly interesting and did not draw on his core skills. The alternative to fixing the setup was continuing to absorb that cost and continuing to wait for the next certificate warning to reach marketing's inbox.
Finding the tool in one search query and committing in a couple of weeks
Samuele does not remember the exact moment the decision crystallised. There was no specific incident, no executive ask, no quarterly review that flagged this as a problem. He simply decided one afternoon to search for something that would handle TLD redirects with the certificate work taken off his plate. The query was a generic one along the lines of TLD redirect solution. redirect.pizza came up among the first hits.
The evaluation that followed was short by enterprise software standards. He opened a free account, configured five domains, ran them for a couple of weeks. Nothing surprised him in either direction. The setup was, in his words, totally intuitive. There was no procurement cycle, no vendor questionnaire, no internal sign-off chain. The plan was small enough that he could decide independently and did. He has been on the paid plan ever since, currently running about eighty of his hundred-domain quota.
What is striking in the decision is what was not part of it. Samuele did not benchmark redirect.pizza against Cloudflare Page Rules, AWS CloudFront, his registrar's native forwarding, or any other obvious adjacent option. He found the first tool that visibly solved the problem, tested it, and stayed. The absence of a competitive evaluation is not carelessness. It is what happens when a product matches the buyer's specification well enough on the first encounter that no second look is warranted.
I had the solution. It was not a very comfortable one because I had to write scripts to do the redirection. Now, it is way more easy. I can delegate this to others if necessary. No effort, big results.
What the work looks like when redirects have stopped feeling like work
Two and a half to three years into using redirect.pizza, the day-to-day pattern is the one Samuele wanted at the outset. The console gets opened only when a new redirect needs to be configured. The last visit before the most recent batch was six months earlier. There was no maintenance, no certificate renewal alert, no broken redirect to investigate.
The most recent batch is itself instructive. Twenty-five new redirects were added in a single month, driven by a brand rebranding inside the group. Each redirect previously took twenty minutes of script-writing and DNS coordination. Through redirect.pizza, the same twenty-five redirects took about ninety minutes in total, end to end, including the corresponding DNS records on the registrar side. The work that used to define a slow week now fits into one part of one morning.
Marketing has not had a certificate-related complaint since the migration. Support tickets to redirect.pizza have not been needed. The two-person team has not had to think about Let's Encrypt rate limits, renewal cron jobs, or expiry alerts. The whole layer of operational anxiety that previously surrounded the legacy-domain portfolio has dissolved.
It helps you manage the redirects in a quick and enjoyable way, without having to worry about lifecycles, certificates, scripts, and so on.
What this case quietly settles about how to size a TLD-redirect tool
The instinct in enterprise software procurement is to assume that a large organisation needs a large tool. Four hundred domains, thirty-five countries, an HR multinational with five brands: that is a profile a vendor like Cloudflare or AWS would be confident addressing. redirect.pizza sits in a different category. It does one thing. It does not host DNS. It does not offer page rules, web application firewalls, or analytics. It handles TLD redirects with automatic HTTPS via Let's Encrypt underneath. For an IT team that already owns DNS and only needs the redirect-plus-certificate layer, that narrower scope is a feature, not a limitation.
The result, in Samuele's hands, is a tool he opens twice a year and forgets about between visits. That is the test of a well-fitted operational tool: not whether it has the most features, but whether it disappears once it is configured. The criterion he would name in a recommendation conversation is simple. If the organisation manages a lot of brands, a lot of domains, and a lot of legacy redirects, this is a very easy way to handle that work. The qualifier is honest. It is not for everyone. It is for the IT team that already knows it has a TLD-redirect problem and wants to stop solving it from scratch.
Simple requirements, simple solution. That is it for me.
