Project estimation
From an early estimate to a proposal you can stand behind
A client wants to migrate their existing tracking to server-side tagging—and expects a credible estimate upfront. But the number of tags does not determine the scope. The real drivers are the unknown dependencies between the data model, consent, platforms, testing, and the teams involved.
That is where agencies and freelancers run into trouble: a setup that looks manageable at first may reveal its true complexity only during the audit, migration, or sign-off. This article shows you how to break the full migration lifecycle into work packages you can price, account for uncertainty in your proposal, and keep implementation, project management, and ongoing operations clearly separated.
Project scope
No two SST projects are alike
Existing tracking setups vary enormously, which makes them difficult to estimate.
Manageable installation
At one end are relatively straightforward installations: one web container, Google Analytics 4, a few Google Ads conversions, and a clean Data Layer.
Organically grown setup
At the other are containers that have grown over many years, with numerous tags, custom JavaScript solutions, multiple marketing platforms, different consent dependencies, and several service providers or internal teams involved.
Both may appear in a proposal under the same label: “migration to server-side tagging.” Yet the actual workload can differ enormously. Tag count is only one signal. What matters more is the variety of implementations and their dependencies on specific data, triggers, consent settings, or other tags.
A container with 30 very similar Google Ads tags can be easier to migrate than a container with ten different tags, each with its own technical and organizational dependencies. A reliable estimate therefore starts not with implementation, but with an audit of the current setup.
Audit
Treat the audit as a project phase of its own
Before you can plan the migration, you need a clear picture of the existing setup. Key questions include:
- Which web containers and properties are in scope?
- Which tracking and marketing platforms are being used?
- Which data is currently sent to which third parties?
- Which tags use templates, and which rely on Custom HTML or custom scripts?
- Which data comes from the Data Layer?
- Which consent dependencies exist?
- Which tags should actually be migrated to server-side tagging?
- Which tags should intentionally remain client-side?
Documentation for older containers and long-running setups is often incomplete or outdated. The first part of the project may therefore be reconstructing the current state. This discovery work is not a free pre-project exercise: a thorough audit is billable professional work and the basis for every decision that follows.
For larger or unfamiliar setups, it can therefore make sense to treat the audit and implementation as separate project phases. The audit then provides the evidence needed to estimate the migration with much greater confidence.
Design & implementation
Technical migration is only one part of the project
Once the existing setup is understood, solution design begins. You need to decide which data should pass through the server container in the future, which changes are required in the web container, and what the new data flow should look like. Typical tasks can include:
- Set up the server container
- Configure the tagging domain
- Set up or coordinate DNS records
- Adapt the web container
- Route GA4 through the server container
- Migrate Google Ads tracking
- Integrate additional third-party platforms
- Configure clients, tags, triggers, and variables in the server container
- Pass consent signals correctly
- Integrate additional features or plugins
Additional edge cases will often emerge. That is the challenge when estimating the work: technical implementation is the most visible part of the project, but not necessarily the largest share of the work. In larger organizations in particular, testing and coordination can take as much time as—or more than—the implementation itself.
Quality assurance
Testing needs to be planned from the start
An SST project is not complete just because requests are reaching the server container. The entire data flow has to continue working correctly. Testing should therefore cover several layers. At a technical level, you need to confirm that requests flow correctly from the browser through the tagging domain to each destination platform.
1
Browser
The intended events and consent signals are triggered.
2
Tagging domain
Requests reach the intended endpoint.
3
Server container
The correct client processes the requests and fires the intended tags.
4
Destination platform
The platform accepts requests, events, and parameters as expected.
You should also verify:
- Are events triggered correctly?
- Are event names and parameters correct?
- Is consent implemented correctly?
- Is any data sent twice?
- Are events or parameters missing?
- Are conversion IDs and other important parameters passed correctly?
- Are requests accepted by the respective platforms?
For critical integrations, checking in Google Tag Manager Preview Mode that tags fire and requests reach the server container is not enough. You also need to verify that the requests contain the expected parameters and consent signals, that the correct client processes them in the server container, and that they are forwarded correctly to each destination platform. Finally, check the resulting data in the destination platforms themselves. Project estimates often overlook this work.
Coordination & sign-off
The more stakeholders are involved, the longer sign-off takes
Tracking infrastructure is rarely owned by one person alone. The analytics team may own Google Analytics, while the paid search team or an external agency manages Google Ads, another provider handles affiliate tracking, and yet another team owns paid social. The technical migration may therefore be complete while business sign-off is still underway. Each stakeholder should confirm that their integration continues to work as expected after the migration. That coordination takes time, and technology can do little to speed it up.
In practical terms, project management and coordination need to be scoped as distinct parts of the project. When several parties are involved, set aside a separate budget for this work.
A clear definition of responsibilities is equally important. Who tests which platform? Who signs it off? And what happens if an external stakeholder does not respond for several days? These questions directly affect the timeline and workload.
Migration strategy
Direct cutover or parallel run?
Another important decision concerns the migration approach.
Direct cutover
An existing setup can be moved directly to server-side tagging, which is often the simpler technical approach. But the cutover changes the data baseline immediately. If the numbers shift afterward, it may be difficult to tell whether server-side tagging caused the change or whether it simply reflects normal variation.
Parallel run
The alternative is to run the old and new setups side by side for a defined period. This makes the results easier to compare, but running both setups cleanly in parallel can be considerably more complex.
Duplicate events must be avoided. Cookies or identifiers can interfere with one another, consent dependencies need to be handled, and a shared Data Layer can create further side effects.
A parallel run should therefore not be the default assumption in the project plan. It is a deliberate project decision that may require additional design, implementation, and testing.
Follow-up monitoring
You cannot always judge the success of an SST migration right away
Go-live is followed by another difficult phase: evaluation. You can usually confirm fairly quickly whether requests are being processed correctly. Determining whether data quality has actually improved takes longer. Some effects of server-side tagging appear immediately; others need time. This is especially true when longer cookie lifetimes or more stable identifiers are expected to improve user or conversion attribution over time.
Normal fluctuations can also result from:
- Seasonality
- Campaigns
- Changes in media budgets
- Consent rates
- Website traffic
- Conversion Rates
- Changes to the website
- Changes made by the platforms themselves
Comparing two figures after only a few days can quickly lead to the wrong conclusions. Without a true parallel run, it is particularly difficult to attribute changes clearly to the SST migration. The project plan should therefore include a follow-up monitoring phase.
Ongoing operations
An SST stack still needs ongoing maintenance
Server-side tagging adds another technical layer to the existing tracking system. The benefits come with additional complexity. Before handover, decide who will own the new system over the long term:
- Who monitors whether the tagging server is available?
- Who detects errors in data transmission?
- Who responds when one of the platforms changes?
- Who maintains the web and server containers?
- After the web container changes, who verifies that the server-side data flow still works correctly?
- Are regular technical reviews in place?
This can support a separate service offering. An agency might provide regular post-project checks or offer an ongoing tracking retainer. The important point is not to let this phase disappear into the original project scope.
Infrastructure
Hosting belongs in the project plan too
The project plan must also define who will provide and operate the server container infrastructure.
Self-operated infrastructure
Agencies can build and manage this infrastructure themselves. In that case, operations, scaling, maintenance, and ongoing infrastructure costs must also be reflected in their proposal.
Outsource infrastructure operations
Alternatively, infrastructure operations can be separated from the implementation project. ProxyRiders is built for practitioners and organizations that want to use Google Tag Manager server-side tagging without operating their own server infrastructure.
For agencies and freelancers, this can simplify estimation: they focus on solution design, tracking implementation, and data quality, while hosting and technical server operations are handled as a standardized component.
Estimation model
A model for project estimation
Total effort =
Analysis + Solution design + Implementation + Testing + Coordination + Release + Follow-up monitoring + Operations
The size of each block depends on the individual project. Typical cost drivers include:
- Number and condition of existing containers
- Number of tracking platforms integrated
- Amount of custom implementation work
- Quality of the existing Data Layer
- Complexity of the consent setup
- Number of stakeholders
- Required testing scope
- Parallel run or direct cutover
- Documentation requirements
- Client training
- Post-migration support requirements
- Hosting and infrastructure model
Structuring the estimate this way makes the resulting proposal more defensible.
Proposal strategy
Make uncertainty explicit instead of pricing too tightly
The hardest SST projects are not necessarily the ones with the most tags. The real risk lies in projects where many dependencies are still unknown before work begins. Your proposal should account for that uncertainty.
Fixed price: For a manageable setup, a fixed price may be appropriate.
Two-stage approach: For complex or organically grown tracking landscapes, start with an audit to define the migration scope. Then price the implementation based on what the audit reveals.
This turns a rough estimate into a project plan you can stand behind—and reduces the risk that essential work only surfaces during implementation.
Conclusion
Estimate the migration, not just the server container
Server-side tagging is technically manageable. The real challenge for freelancers and agencies is scoping the migration as a complete project. The server container is only one part of the workload: audit, solution design, testing, stakeholder sign-offs, release, follow-up monitoring, and ongoing operations all need to be accounted for.
Account for all of these components and you can build more realistic proposals while avoiding debates about work that suddenly surfaces as “additional effort” once delivery is underway. For server-side tagging in particular, the offer should cover a clearly defined process—not just the technical implementation.
Next step
Separate project delivery from infrastructure operations
ProxyRiders handles hosting, scaling, updates, and technical operation of the GTM tagging server. You can keep solution design, implementation, testing, and client sign-off clearly defined and predictable within your scope of work.