The first 30 days with a new Magento agency set the trajectory for the next two years. The patterns that emerge in this window, around responsiveness, technical depth, communication discipline, and operational ownership, almost never improve later. If the agency is going to be a strong partner, the evidence will be visible by day 30. If not, the warning signs will be visible too, and acting on them in week four is far cheaper than acting on them in month nine.
The playbook below is the one Bemeir’s Magento team uses for inherited engagements, both from our own onboarding side and as advisors to clients evaluating other agencies. The deliverables are specific because vague onboarding produces vague relationships.
Week 1: Knowledge transfer and access
The first week is dominated by knowledge transfer from the outgoing team or in-house staff. The non-negotiable deliverables:
Credentials inventory. Every credential the store depends on, documented in a password manager or vault: hosting, admin accounts, third-party services, payment processors, ERP integrations, monitoring tools, deployment systems. Each credential should have a named owner on both the client and agency side.
Code repository access and branch strategy. The new agency should have commit access to your repository with their own named users, not a shared account. The branch strategy (main/develop/release) should be documented and any quirks (off-repo patches, vendor modifications) called out explicitly.
Infrastructure walkthrough. A 90-minute call with whoever owns the infrastructure: hosting provider, cloud team, or in-house ops. The new agency needs to understand the deployment process, the staging-to-production flow, the backup posture, and the recovery procedure. If you are on Adobe Commerce Cloud, the walkthrough is shorter but still required.
Integration map. A document listing every external system the store talks to, the protocol used, the credentials owner, and the failure mode if the integration is down. Most stores discover at this stage that two or three integrations exist that nobody had remembered.
The agency should be asking sharp questions during this week. Vague questions or passive note-taking is a warning signal; they should be probing for the gaps in your documentation, because those gaps are where the surprises live.
Week 2: Initial audit and risk register
In week two, the agency produces an initial audit and risk register. This document should run 4-8 pages and cover:
Platform health. Magento version, patch level, PHP version, MySQL/MariaDB version, third-party extension versions. Each gap from current state to recommended state should be quantified and prioritized.
Performance baseline. Core Web Vitals current state on top page types, captured via Lighthouse or real-user monitoring data. This becomes the baseline you measure against for the rest of the engagement.
Security posture. Open security patches, exposure surface, known vulnerabilities in installed extensions. The agency should reference the Adobe Security Bulletins and Sansec research where relevant.
Codebase risks. Custom modules of unclear purpose, vendor modifications, deprecated patterns, code quality concerns. Each risk should have a severity (P0/P1/P2/P3) and an estimated remediation effort.
Operational risks. Failing cron jobs, broken integrations, untested backups, missing monitoring. These often outnumber the code-level risks and are usually faster to fix.
The risk register is the agency’s first real artifact. It tells you whether they have done the work, whether they are willing to give bad news in writing, and whether they understand prioritization.
Week 3: Quick wins and process establishment
Week three is where momentum either builds or stalls. The agency should ship 2-4 small but real improvements: a security patch applied to staging and validated, a known performance regression fixed, a broken cron job restored. These are not glamorous deliveries but they prove the team can execute.
In parallel, the operational rhythm gets established:
| Operational element | What good looks like |
|---|---|
| Standup or async check-in | Daily, ~10 minutes, focused on blockers |
| Sprint cadence | 1 or 2-week sprints with explicit goals |
| Code review | Every PR reviewed by named senior engineer, with written feedback |
| Patch and deployment process | Documented, repeatable, environment-promoted (staging → production) |
| Monitoring and alerting | Subscribed by the new agency, with explicit escalation paths |
| Status reporting | Weekly written summary, not just verbal updates |
| Backlog and prioritization | Maintained jointly, with explicit P0/P1/P2 designation |
If three or more of these are still informal at the end of week three, the agency is treating the engagement as transactional rather than operational. That choice has consequences for every month after.
Week 4: Roadmap and the first hard conversation
Week four delivers the 90-day and 12-month roadmap. The 90-day roadmap should be specific: which patches, which performance fixes, which feature work, in which sprint. The 12-month roadmap can be more directional but should include the major architectural decisions the engagement will require.
This is also the week where the first hard conversation usually happens. The agency has now done enough work to know what the engagement actually looks like, and there will be at least one thing that costs more, takes longer, or requires more decisiveness than the sales pitch implied. How they raise this conversation, and how they propose to handle it, is the most important signal of the first 30 days.
The healthy version of this conversation is direct: “Here is what we found, here is what we recommend, here are the trade-offs, here is what we need from you.” The unhealthy version is hedged: “We may need to revisit timelines, things are more complex than expected, we will get back to you with details.” The difference is between a partner who owns the engagement and a vendor who is positioning for change orders.
What to measure at the day-30 checkpoint
By day 30, you should be able to answer yes or no to each of the following:
- Did we get a complete risk register in writing?
- Did at least 2 real production improvements ship?
- Is the operational cadence (standups, code review, status reports) established?
- Did the agency raise at least one piece of bad news in writing?
- Do I know by name who is reviewing the code that ships to my store?
- Has the agency named the senior engineer responsible for architectural decisions?
- Is patch and security cadence documented and tracked?
- Is there a 90-day roadmap specific enough to manage against?
A relationship that says yes to seven or eight of these has a high probability of working. A relationship that says yes to four or fewer is in trouble and needs intervention before month two. Five or six is the band where the next 30 days matter most.
What the merchant owes the agency
The first 30 days is a two-way obligation. The merchant’s side of the bargain:
Single point of decision. The agency needs one person on the client side who can make calls quickly. Distributed decision-making at this stage stalls every cycle.
Access without friction. Credentials, documentation, prior agency contacts, and operational records should be available within 48 hours of a request. The merchant who slow-rolls access during onboarding has set the worst possible tone.
Honesty about constraints. Budget, deadlines, internal political constraints, and stakeholder expectations should all be on the table in week one. The agency that knows the constraints can plan around them. The agency that does not is going to deliver work that fits the wrong constraints.
Willingness to hear bad news. If the agency raises a risk in writing and the merchant punishes them by treating it as a sales gimmick, the agency will stop raising risks. That is a worse outcome than expensive change orders.
A strong first 30 days does not guarantee a great two-year relationship, but a weak first 30 days reliably predicts a bad one. The team that ships the right deliverables in the right window, with the right operational discipline and the right tolerance for hard conversations, is the team you can trust with the bigger work that follows. The team that does not is the team you replace before they become the next inherited engagement. Bemeir’s onboarding playbook for Magento engagements is built on this same 30-day framework because it is the version that consistently predicts which relationships are going to work.
