_Prostock-studio_Alamy.jpg?width=1280&auto=webp&quality=80&disable=upscale#)
![What’s new in Android’s May 2025 Google System Updates [U: 5/19]](https://i0.wp.com/9to5google.com/wp-content/uploads/sites/4/2025/01/google-play-services-1.jpg?resize=1200%2C628&quality=82&strip=all&ssl=1)
.webp?#)
![[The AI Show Episode 147]: OpenAI Abandons For-Profit Plan, AI College Cheating Epidemic, Apple Says AI Will Replace Search Engines & HubSpot’s AI-First Scorecard](https://www.marketingaiinstitute.com/hubfs/ep%20147%20cover.png)
![How to make Developer Friends When You Don't Live in Silicon Valley, with Iraqi Engineer Code;Life [Podcast #172]](https://cdn.hashnode.com/res/hashnode/image/upload/v1747360508340/f07040cd-3eeb-443c-b4fb-370f6a4a14da.png?#)
219/365 | ¥10M Job Challenge - Process for taking over a project
Process for taking over and maintaining a project: Log in to the application server by VPN or SSH in order to understand where the project files are stored and how the deployment process works. Typically, we'll start with the HTTP server and service-related files. Log in to the database to ensure we can connect properly. Ideally, take this opportunity to dump and back up the database schema as an SQL file. Even if the project originally followed a Code First approach with migration files, it's very common for projects to shift toward a DB First setup over time, especially after being handed off between multiple developers. Not having a complete DB schema can often lead to major issues. Check how the connection strings and environment variables are applied, then run the project locally for testing. If there are too many third-party services making it hard to run locally, writing mock services could take a lot of time. In that case, the best approach is to see if we can run the project locally while connecting to the actual staging/production database for testing. (But make sure to check for background services or scheduled jobs that could cause concurrency issues.) I'll add more if anything else comes to mind. In many cases, taking over a project can be chaotic and unstructured—blindly following AI suggestions without critical thinking can easily lead to disaster.
Process for taking over and maintaining a project:
Log in to the application server by VPN or SSH in order to understand where the project files are stored and how the deployment process works. Typically, we'll start with the HTTP server and service-related files.
Log in to the database to ensure we can connect properly. Ideally, take this opportunity to dump and back up the database schema as an SQL file. Even if the project originally followed a Code First approach with migration files, it's very common for projects to shift toward a DB First setup over time, especially after being handed off between multiple developers. Not having a complete DB schema can often lead to major issues.
Check how the connection strings and environment variables are applied, then run the project locally for testing. If there are too many third-party services making it hard to run locally, writing mock services could take a lot of time. In that case, the best approach is to see if we can run the project locally while connecting to the actual staging/production database for testing. (But make sure to check for background services or scheduled jobs that could cause concurrency issues.)
I'll add more if anything else comes to mind. In many cases, taking over a project can be chaotic and unstructured—blindly following AI suggestions without critical thinking can easily lead to disaster.
