Before any technical work, sort out control. This is urgent if the previous relationship ended badly and worth doing regardless.<\/p>\n
Confirm you are the Shopify store owner<\/a>,<\/strong> not a staff member. Check the settings rather than assuming. If the store was created under a developer’s account, transferring ownership<\/a> is a defined process and it should happen immediately.<\/p>\n Check your domain registration.<\/strong> Who is the registrant, where is it registered, and do you have the login? Domains registered in a developer’s name are a common and serious exposure.<\/p>\n Audit staff and collaborator access.<\/strong> Remove anyone who should no longer have it. Previous developers routinely retain collaborator access for years after a relationship ends, usually harmlessly and occasionally not.<\/p>\n Check app billing.<\/strong> Apps subscribed under a developer’s account will lapse or remain under their control. Move them to your billing.<\/p>\n Locate your third-party accounts.<\/strong> Email platform, analytics, Search Console, ad accounts, review app, payment gateway. Confirm you have owner access to each, not access granted by someone else.<\/p>\n Check your theme store purchases<\/strong> and where the licence sits.<\/p>\n Take a full backup<\/a>.<\/strong> Export products, customers, and orders, and download a copy of the live theme. Do this before anyone changes anything, and store it somewhere you control.<\/p>\n Change any shared passwords<\/strong> and enable two-factor authentication on everything.<\/p>\n That list takes a morning and eliminates most of the leverage a departed developer might otherwise hold, deliberately or not.<\/p>\n The new developer’s first task is understanding what exists. Rushing this is how inherited stores get broken.<\/p>\n Identify the live theme and any others.<\/strong> Stores frequently have several, and it is not always obvious which is live or what the others were for. Duplicate the live theme immediately as a dated backup that nobody touches.<\/p>\n Read the theme for modifications.<\/strong> What has been customised, where, and how invasively. Look for code added directly to core theme files, which is the main reason a theme cannot be updated safely.<\/p>\n Find code left behind by uninstalled apps.<\/strong> Almost every inherited store has snippets loading for apps that no longer exist. This is usually the quickest available performance win<\/a>.<\/p>\n Inventory apps against actual usage.<\/strong> What is installed, what is being paid for, what anyone actually uses, and which ones inject storefront code.<\/p>\n Find the custom functionality.<\/strong> Anything built specifically for this store: calculators, configurators, custom pricing, integrations<\/a>, scripts. For each, establish what it does, how it works, and whether anyone understands it. This is where the real risk sits.<\/p>\n Check for version control.<\/strong> Most inherited stores have none, meaning no history and no way to see what changed when.<\/p>\n Check whether a staging environment exists.<\/strong> Usually not, which means previous changes were made live.<\/p>\n Audit integrations.<\/strong> What connects to what, in which direction, and whether anything is broken or partly broken. Silently failing integrations are common and can go unnoticed for months.<\/p>\n Baseline the technical state.<\/strong> Core Web Vitals on mobile for the main page types, structured data validation, a crawl for broken links and redirect chains, and heading structure. You need this before you change anything, so improvement is measurable.<\/p>\n Baseline the commercial state.<\/strong> Conversion by device and page type, organic traffic by landing page, and revenue by channel. Same reason.<\/p>\n Check for security and hygiene problems.<\/strong> Old staff accounts, exposed credentials in theme code, hard-coded API keys, and anything obviously unsafe.<\/p>\n Document what you find,<\/strong> including the things nobody can explain. “Nobody knows what this does” is a legitimate and useful audit finding.<\/p>\n Nearly every developer inheriting a store wants to rebuild it, and the reasoning deserves scrutiny.<\/p>\n Unfamiliar code always looks worse than it is.<\/strong> Someone else’s structure, naming, and decisions feel wrong because they are unfamiliar. Some of it really is bad. Much of it is simply not how you would have done it, which is not the same thing.<\/p>\n The existing store encodes decisions you cannot see.<\/strong> That odd conditional in the cart template may handle a real edge case discovered through eighteen months of support tickets. Rebuilding discards that accumulated knowledge, and you rediscover it through the same tickets.<\/p>\n Rebuilding carries the same risks as a migration.<\/strong> Lost content in sections, changed structured data, altered heading structure, broken app blocks, lost tracking. The theme migration article in the previous batch covers this, and it applies fully here.<\/p>\n It delays the improvements that matter.<\/strong> A rebuild consumes months during which nothing else improves. Meanwhile the store might have a five-second mobile load time and a broken abandoned-cart flow that could be fixed in a fortnight.<\/p>\n When a rebuild is justified:<\/strong> the theme is so heavily and badly modified that safe changes are impossible; performance problems are structural rather than additive; the theme is very old and unsupported; or the business has changed enough that the store no longer fits. Those are real situations. They are less common than the instinct suggests.<\/p>\n The better default:<\/strong> stabilise, fix the highest-value problems incrementally, and rebuild deliberately later if the case still holds after six months of familiarity. By then you will know which parts need replacing.<\/p>\n A sequence that works.<\/p>\n Weeks 1\u20132: secure and audit.<\/strong> Everything above. Change nothing except access control.<\/p>\n Week 2: report.<\/strong> The new developer should produce a written assessment: what exists, what is broken, what is risky, what is undocumented, and a ranked list of recommendations with effort and expected impact. This document is the main deliverable of a takeover and it is what you are paying for.<\/p>\n Weeks 3\u20134: set up the basics.<\/strong> A staging environment. Version control. A backup routine. Documentation of the custom functionality, starting with whatever is least understood and most business-critical. These are unglamorous and they are what makes everything afterwards safe.<\/p>\n Weeks 4\u20138: fix the cheap high-value problems.<\/strong> Orphaned app code. Unused apps. Image handling. Broken links and redirect chains. Silently failing integrations. Missing or incomplete structured data. These are typically quick and produce visible results, which also builds confidence in the new relationship.<\/p>\n Weeks 8\u201312: address the substantial items<\/strong> from the ranked list, in order of value. And revisit the rebuild question with three months of actual knowledge rather than a first impression.<\/p>\n Throughout: document as you go.<\/strong> The main failure of the previous arrangement was probably that nobody wrote anything down. Do not repeat it.<\/p>\n A gifting retailer came to us after their developer of five years became unreachable. The store worked and generated good revenue, and nobody could change anything.<\/p>\n The audit explained why. The theme had been modified extensively in core files rather than through sections, so it could not be updated. There was no version control and no staging \u2014 every change for five years had been made directly on the live theme. There were snippets from eleven previously uninstalled apps. A custom gift-message and delivery-date system, central to the business, existed as several hundred lines of undocumented JavaScript in a single file with no comments.<\/p>\n Their previous quotes from other developers had all proposed a full rebuild, at significant cost and a four-month timeline.<\/p>\n We proposed something different. Two weeks documenting the gift-message system by reading it and testing its behaviour systematically \u2014 which produced a written specification of what it actually did, including three behaviours nobody in the business knew about. Then a staging environment, version control, and a dated backup of the live theme.<\/p>\n Then eight weeks of incremental work: removing the orphaned app code, which took their mobile load time from 5.1 seconds to 2.8; fixing image handling; repairing an accounting integration that had been failing silently for seven months; and moving the gift-message system into a properly structured, commented implementation without changing its behaviour.<\/p>\n After three months the store was maintainable, considerably faster, and documented. The rebuild everyone had proposed was no longer necessary, and if it ever becomes necessary it can now be done safely because somebody knows what the store does.<\/p>\n Total cost was well under half the cheapest rebuild quote.<\/p>\n “What will you do in the first two weeks?”<\/strong> The answer should be audit and documentation, not building. Anyone proposing changes in week one has not looked yet.<\/p>\n “Will you give me a written assessment?”<\/strong> This should be the first deliverable. If it is not offered, ask for it explicitly and expect to pay for it.<\/p>\n “What is your view on rebuilding versus improving?”<\/strong> You want someone who will consider both and justify their recommendation, not someone whose answer was decided before they looked.<\/p>\n “How will you handle the custom functionality nobody understands?”<\/strong> Reading, testing, and documenting it is the right answer. Replacing it immediately is not, unless they can explain why.<\/p>\n “What will you set up that does not exist?”<\/strong> Staging, version control, and backups should be on the list.<\/p>\n “How will you document things?”<\/strong> And insist it happens continuously rather than as a final deliverable.<\/p>\n A note for the departing side, since takeovers are smoother when the handover is decent and most of this costs very little.<\/p>\n Hand over without being asked.<\/strong> Credentials, documentation, an explanation of custom work, and the reasoning behind non-obvious decisions. It takes a few hours and it is the difference between a professional exit and a client who describes you unfavourably for years.<\/p>\n Explain the odd decisions.<\/strong> The strange conditional, the workaround, the thing that looks wrong. If there was a reason, write it down. Otherwise your successor will remove it and rediscover the problem, and you will be blamed for both.<\/p>\n Transfer ownership of everything.<\/strong> Store ownership, domain, app subscriptions. Do not wait to be chased.<\/p>\n Remove your own access<\/strong> once handover is complete, and tell them you have.<\/p>\n Be available briefly afterwards.<\/strong> An hour or two for questions in the following fortnight costs almost nothing and is remembered. Charge for it if the relationship warrants charging.<\/p>\n Do not leave landmines.<\/strong> Deliberately obscure code, undocumented dependencies, or anything designed to make you necessary. It is unprofessional, it damages your reputation in a small industry, and clients talk.<\/p>\n The commercial argument for handing over well is simple: the client who leaves you smoothly may come back, and will certainly be asked for a recommendation at some point.<\/p>\n Changing things in week one.<\/strong> Before anyone understands what exists. This is how inherited stores break, and the damage is often hard to attribute because nobody has a baseline.<\/p>\n Skipping the baseline measurements.<\/strong> Without recording Core Web Vitals, conversion by device, and organic traffic by page before you start, you cannot demonstrate improvement or detect damage. Both matter.<\/p>\n Trusting the previous developer’s documentation.<\/strong> Where it exists, verify it. Documentation drifts out of date, and an inherited document describing how something worked two years ago is worse than no document if it is believed.<\/p>\n Assuming everything is broken.<\/strong> New developers often condemn the whole store to justify a larger engagement. Some inherited stores are built perfectly well by someone who simply moved on.<\/p>\n Assuming nothing is broken.<\/strong> Equally common on the client side. A store generating revenue can still have a failing integration, a broken email flow, or a checkout problem affecting one segment. Check rather than infer from the revenue figure.<\/p>\n Not fixing the infrastructure gap.<\/strong> If you take over a store with no staging, no version control, and no documentation and do not address those, you have inherited the previous arrangement’s central flaw and will hand the same problem to the next developer.<\/p>\n Letting the audit become the project.<\/strong> Two weeks of audit is proportionate. Two months is a way of billing without delivering, and you should expect the written assessment and a ranked plan at the end of the first fortnight.<\/p>\n Secure your accounts first \u2014 ownership, domain, app billing, and third-party access \u2014 because that takes a morning and removes most of your exposure.<\/p>\n Then insist on an audit before any changes, with a written assessment as the deliverable. What exists, what is broken, what is undocumented, and a ranked list of what to do about it.<\/p>\n Resist the rebuild instinct, on both sides. It is occasionally right and usually premature, and the alternative \u2014 stabilise<\/a>, document, then improve incrementally \u2014 delivers visible results in weeks rather than months while keeping the option open.<\/p>\n And set up the boring infrastructure early: staging, version control, backups, and documentation. The reason your last arrangement left you stuck is almost certainly that none of those existed, and no amount of theme work<\/a> substitutes for them.<\/p>\n<\/span>Then: the audit, before anything is changed<\/span><\/h2>\n
<\/span>Why rebuilding is usually the wrong first move<\/span><\/h2>\n
<\/span>The first ninety days<\/span><\/h2>\n
<\/span>A worked example: the store nobody could change<\/span><\/h2>\n
![\"Four-step](\"https:\/\/www.liquidwebdevelopers.com\/blog\/wp-content\/uploads\/2026\/10\/266-taking-over-a-store.svg\")
<\/span>What to ask a developer taking over your store<\/span><\/h2>\n
<\/span>Leaving well, if you are the one leaving<\/span><\/h2>\n
<\/span>Common takeover mistakes<\/span><\/h2>\n
<\/span>The bottom line<\/span><\/h2>\n
<\/span>Frequently asked questions<\/span><\/h2>\n
<\/span>What should I do first when changing Shopify developers?<\/span><\/h4>\n