How would you accept the project for support / maintenance?

Question

System administration

Imagine the situation - you (companies) have been sold an existing project and you are accepting it for operation. You are a system engineer, on which the entire infrastructure / database / software. How would you take it? What points would you take into account? Project och. large, the stack is something like this - apache/nginx/php/couchbase/mysql/rabbitmq/cassandradb/memcached/etc with kubernetes/ansible-em/docker and other technology zoo.

Answer 1

1) You need to understand what this project does, and whether it fulfills the tasks assigned to it. Are there any features not yet implemented, unclosed bugs that only a couple of people know about. Because there is a feature on paper, but in fact it is not 100% done yet, but only some modules have been laid down for future modules, or a bug that is reproduced in a certain sequence, but the probability of hitting it is extremely small. You also need to understand the number of users for this project, the more the worse for you, because the availability of the project should be at least 99.95%
2) If I were to accept a project with such a stack of technologies and all the support would fall on me, I would demand documentation for this project, everything that is and is not there will have to be added by the old employees. And additional support for at least 6 months (possibly paid, here you need to consider options).
3) Understanding the stack that is used, if you know all these technologies at an average level, then it’s good if you don’t look for outsourcing people who will explain to you what’s what and help keep the project afloat for money.
4) Be sure to order an audit from disinterested parties. If the budget allows, then from two companies. Also check the modules / code that are used in the project for "legal purity", so that there are no restrictions on the sale of the project, the provision of commercial services by the project (paid subscriptions, etc.) because there are modules that are free for your own use, but paid for commercial use (this includes the sale of the project, and the provision of paid options to users of the project, etc.). Well, so that in which case the problems fell on the developer or the company that did the audit.
5) Understand your competence, how ready you are to be responsible for what is being passed to you. Again, the project was developed by a whole team, and now it is being blamed entirely on you. Are you able to support this project? And develop, fix bugs? If not, then the first thing to do is look for people who can, and take everyone in place. Divide the project into parts and divide these parts between competent employees who are able, in which case, to argue their decision/opinion.
Well, for starters, something like this, what came to mind right away, in fact, there is still a lot of things. It all depends on the specific situation.

Answer 2

At the very least, you cannot make any guarantees.
Accept the project, study it and support it. The price depends on the complexity, documentation and many, many other things.
Usually, after a change of ownership, for some time the old team works in parallel and brings things up to date.

Answer 3

If we discard professional skills, i.e. assume that everyone is competent in all parts of the project, then I advise you to ask the transferring party for all the current jambs, flaws and crutches so you will immediately understand the true state of affairs.
If there are gaps in the technologies used, then it is better to immediately declare this at least to your personal management, and maybe to the customer.
If the project is standalone (does not require 24/7 support), then documentation is your best friend, otherwise there will be no time for documentation, this is a common practice in large projects.
And finally, the users. How quickly you adapt to the project depends on their adequacy, sometimes users can tell more than the developer)