[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-taking-over-a-software-project":3,"blog-post-adjacent-taking-over-a-software-project":67},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":13,"datePublished":14,"dateModified":14,"category":15,"author":19,"tags":26,"answerFirst":31,"keyTakeaways":32,"body":38,"faqs":39,"sources":58,"relatedServices":59,"seo":63},"ncxjd94c3l20meh2j5irhwas","Taking Over a Software Project: What the Business Must Own","taking-over-a-software-project","The code is the easy part to recover. Before an outgoing team stops answering, secure the repository account, the signing keys, the domain, the deployment path, and the known issues list.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_06_exports_drieverse_b06_blog_16x9_2400x1350_36986e2bbe.jpg",2400,1350,null,"Taking Over a Software Project: What to Secure","2026-09-21",{"name":16,"slug":17,"description":18,"seo":12},"Engineering","engineering","Software architecture, code quality and the engineering practice behind the systems we build.",{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":12,"photo":12,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29],{"name":28,"slug":28},"risk-management",{"name":30,"slug":30},"process-design","Taking over a software project means securing the assets the business cannot reconstruct on its own: the accounts that own the repositories, the signing keys and store listings, the domain and DNS, the deployment path from commit to production, the licences registered to individuals, and an honest list of known issues. The source code is the part you can always read later.",[33,34,35,36,37],"Order a takeover by recoverability, not importance. Source code can be read at any time. A signing key, a store listing, or a domain held in somebody else's personal account can become unrecoverable the week after the relationship ends.","Access to a repository is not ownership of it. Ask who owns the organisation the repository sits in, and move the project into an account the business controls before anything else in the transition starts.","A zip of the source is not a repository. The commit history, the pull request discussions, and the issue threads are where the reasons live, and the reasons are the part nobody can write down for you later.","Licences and third-party accounts registered to an individual are the quietest failure. They keep working until a card expires or a mailbox is closed, months after the takeover looked complete.","A vendor who reports no known issues has not finished the handover. Ask what they would not touch on a Friday, and make it safe to answer honestly.","A software project changes hands more often than most roadmaps allow for. An\nagency relationship ends, a contractor takes a permanent job, a team is\nrestructured, and somebody inherits an application they did not build.\n\nThe code is the part everyone asks about first. It is also the part least at\nrisk, because either it is in a repository or its absence is obvious within an\nhour. What goes missing is everything arranged around the code: the account\nthat owns the repository, the key that signs the mobile build, the reason the\npayment integration works the way it does.\n\nSo the useful way to order a takeover is not by what matters most. It is by\nwhat you cannot reconstruct once the outgoing team stops answering.\n\n## Rank the assets by how hard they are to recover\n\nThree tiers, and the order you work in should follow them.\n\n**Effectively unrecoverable without the outgoing party.** Code signing keys\nand publishing accounts, the domain registrar login, the merchant account at a\npayment provider, and historical data that exists in one place. These are\nassets where a lost credential is not an inconvenience. Losing the key an app\nwas signed with can mean existing installations cannot be updated at all,\nonly replaced by a new listing that every user has to install again.\n\n**Recoverable, at a cost you would rather not pay.** The deployment path,\nenvironment configuration, scheduled jobs, and the decisions behind the\narchitecture. All of it can be reverse engineered from a running system by\nsomebody competent, and doing so consumes weeks that were meant for delivery.\n\n**Cheap to recover.** The source itself, the dependency list, and anything\ngenerated from them. Worth having, never the constraint.\n\nMost takeover checklists are ordered by the third tier because it is the\neasiest to write down. Work the first tier in the week you still have somebody\nto ask.\n\n## Repositories, and the account that actually owns them\n\nAccess to a repository is not ownership of it. Repositories live inside an\naccount or an organisation, and in an agency arrangement that container often\nbelongs to the agency rather than to the business paying for the work.\n\nEstablish three things in this order. Who owns the organisation the\nrepositories sit in. Whether the business has an owner-level seat in it, not a\ncollaborator seat. And whether the contract assigned the intellectual property\nto the business in the first place, because a transfer of files does not\nsettle a question the agreement left open.\n\nThen take the repository, not a copy of it. A zip of the source is a snapshot\nwith the reasoning stripped out. What you want transferred is the full commit\nhistory, the branches and tags that correspond to what is running, the pull\nrequest discussions, the issue threads, any published packages, and the\ncontinuous integration configuration. Half the answers to \"why is this like\nthis\" are in those threads, written at the time by people who knew.\n\nTwo things sit beside the repository and are missed for the same reason.\nRepository secrets used by the build are stored separately from the code and\ndo not travel with a clone. Anything installed as a bot or an app against the\nrepository, including deployment integrations, is authorised by an account\nthat may be leaving with the outgoing team.\n\n## The credentials that never appear on a credentials list\n\nA credentials export covers the systems somebody is thinking about. The ones\nthat matter are usually the ones nobody thinks about until they break.\n\nWork through this list explicitly:\n\n- The domain registrar and the DNS provider, which are often different\n  companies and frequently sit in a personal account\n- Code signing certificates and keystores, along with the app store and play\n  console accounts that publish with them\n- Push notification credentials, which expire on their own schedule\n- The payment provider and the merchant account behind it\n- The domain used to send transactional email, and the records that authorise\n  it to send\n- Error tracking, analytics, and any service holding historical data that\n  restarts at zero if the account is recreated\n- Every third-party API key in use, and which account issued it\n\nFor each one there is a question sharper than \"do we have the password\":\nwhose mailbox receives the password reset. An account the business cannot\nrecover on its own is an account the business does not hold, whatever the\ncredentials document says.\n\nThe billing owner deserves the same treatment. A service paid for on a card\nbelonging to somebody at the outgoing supplier will keep working until it\ndoes not, and the notice will go to them.\n\n## The deployment path, from a commit to production\n\nAsk for the path to be written down end to end, and be specific about what end\nto end means: what triggers a build, where builds run, what the deployable\nartefact is, where configuration and secrets come from at runtime, how\ndatabase migrations are applied, what the rollback procedure is, and who is\npermitted to approve a release.\n\nThe gaps in that document are the useful part. Most projects have one step\nthat only one person performs, and it tends to be the step that is not written\ndown anywhere. It might be a manual cache clear, a flag toggled in a dashboard\nafter every release, or a job somebody runs by hand at month end. Those steps\nare invisible in the code and obvious in the answer to \"what do you actually\ndo when you ship\".\n\nInfrastructure itself, the servers and hosting underneath this, is a separate\nexercise with its own checklist. We wrote that one up separately as\n[what to verify at an infrastructure handover](\u002Fblog\u002Finfrastructure-handover-what-to-verify).\n\n## Documentation worth having, and the kind that is not\n\nMost handover documentation is a description of the code written by somebody\nreading the code. It is the least valuable artefact in the transfer, because\nyou can also read the code.\n\nFour documents earn their place:\n\n1. How to run the project locally, verified on a machine that has never run\n   it, by somebody who is not the author\n2. The deployment path described above\n3. A map of every environment and third-party service, with the account that\n   owns each and what it costs the business to lose it\n4. The decisions and their reasons: why this database, why this integration\n   works this way, what was tried before and abandoned\n\nThe fourth is the one that cannot be regenerated. Everything else in this list\ncan be rebuilt from a running system with enough patience. The reasoning\nbehind a decision exists only in somebody's memory and in the threads attached\nto the work, and it decays quickly once they move on.\n\n## Who the licences are registered to\n\nCommercial libraries, themes, fonts, SDKs, and seat-based services all carry\nlicences, and a licence registered to a person is a licence the business does\nnot hold.\n\nAsk for a list of everything paid for, what it is used for, when it renews,\nand the name and account it sits under. Where something is registered to an\nindividual at the outgoing supplier, transferring it is a task with a vendor\nin the loop and its own lead time, not a checkbox on the last day.\n\nThe other licence question runs the opposite way: the terms of the code you\nare receiving. If the product is distributed rather than run as a hosted\nservice, open source components carry obligations that travel with it. That is\nworth knowing at the point of takeover rather than at the point somebody asks\nfor the source.\n\n## The known issues list nobody volunteers\n\nNo outgoing team opens with the things that are fragile. It reads as an\nadmission, it arrives at the moment they are least inclined to make one, and\nnothing in a standard handover template asks for it.\n\nAsk directly, and make it safe to answer:\n\n- What would you not deploy on a Friday\n- Which test fails occasionally and gets rerun\n- What breaks if this integration is slow rather than down\n- Which part has a workaround in place instead of a fix\n- What do you do by hand that should be automated\n- What has been on the list to fix for a year\n\nA project with no known issues does not exist. A handover that reports none is\nan incomplete handover, and the items will arrive anyway, in the order the\nsystem chooses rather than the order you would have chosen.\n\n## Ship something small while the outgoing team is still there\n\nDocumentation can look complete and still be unusable. The only way to know is\nto use it.\n\nBefore the relationship ends, have somebody from the incoming team take a\ntrivial change all the way through: a commit, a review, a build, a deployment\nto production, a verification that it is live, and a rollback. The outgoing\nteam watches and answers questions without touching anything.\n\nEvery question asked during that hour is a gap in the handover, found while\nthere is still somebody to answer it. It is the cheapest audit available and\nthe only one that produces a fact rather than a document.\n\nIf a supplier transition is coming and you are not certain what the business\nactually holds, that is worth establishing while it is still a paperwork\nexercise. Discuss a project takeover with us before the outgoing team's last\nweek, not during it.",[40,43,46,49,52,55],{"question":41,"answer":42},"What should be included in a software project handover?","Ownership of the repositories and the account they sit in, the full commit history and issue threads, every credential including signing keys and store accounts, the domain and DNS, a written deployment path, a map of third-party services and who owns each, licences with the name they are registered to, and an explicit list of known issues.",{"question":44,"answer":45},"Is access to the code repository enough to take over a project?","No. Access lets you read and clone the code. It does not establish who owns the organisation the repository lives in, whether the intellectual property was assigned to the business, or whether build secrets and deployment integrations travel with it. Ownership of the container matters more than access to the contents.",{"question":47,"answer":48},"Who should own the domain and app store accounts for a business's software?","The business, in an account the business can recover without help. The test is whose mailbox receives the password reset. Registrar accounts, DNS, publishing accounts, and code signing keys held by a supplier are the assets that become genuinely unrecoverable when a relationship ends, so they are the first to move.",{"question":50,"answer":51},"What documentation should you ask for when taking over a software project?","Four things: how to run the project locally verified on a clean machine, the deployment path from commit to production, a map of environments and third-party services with the owner of each, and the decisions behind the architecture with the reasons for them. Descriptions of what the code does are the least useful item, because the code is already readable.",{"question":53,"answer":54},"How do you find out about known issues when a vendor hands over a project?","Ask specific questions rather than a general one. What would you not deploy on a Friday, which test fails occasionally, what has a workaround instead of a fix, and what is done by hand every month. A general request for known issues usually returns nothing, because nothing in a handover template invites the answer.",{"question":56,"answer":57},"How long should a software project takeover take?","Long enough to secure the unrecoverable assets first and to ship one small change through the full deployment path while the outgoing team is still available to answer questions. The sequence matters more than the duration: accounts and keys early, documentation and code review afterwards, because the second half stays possible once the first half is safe.",[],[60,61,62],"software-development","it-consulting","app-development",{"metaTitle":13,"metaDescription":64,"ogImage":65,"canonicalPath":12,"noindex":66},"Changing software supplier? Secure the repository account, signing keys, domain, deployment path, licences and known issues before the outgoing team leaves.",{"url":9,"width":10,"height":11,"alt":12},false,{"prev":68,"next":12},{"id":69,"title":70,"slug":71,"excerpt":72,"cover":73,"coverAlt":77,"datePublished":78,"dateModified":78,"category":79,"author":80,"tags":81},"tvvj273m9sq3gal86fv6ddlu","How to Write a Software Project Brief That Vendors Can Actually Use","how-to-write-a-software-project-brief","If three vendors quote three different projects, the brief may be the problem, not the vendors. Here is what a software project brief actually needs to cover.",{"url":74,"width":75,"height":76,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fexports_drieverse_blog_project_brief_3200x1800_5c78424ec5.jpg",3200,1800,"Dark field-notes cover reading \"One request. Three quotes.\" with the DrieVerse Tech logo, for a post about writing software project briefs vendors can use.","2026-09-15",{"name":16,"slug":17},{"name":20,"slug":21},[82,84,86],{"name":83,"slug":83},"discovery",{"name":85,"slug":85},"decision-frameworks",{"name":30,"slug":30}]