Hi, so relatively new BA (about ready to take Foundation BA BCS qualification).

I'm working in a company which doesn't use BAs for much beyond requirements gathering, certainly very little time outside of this phase so plenty of non-standard practice at least based on what I've learned from the Foundation course. 

I've been tasked to work on a project where an a large number of queues, APIs, files etc. are on an end-of-life data server and they need to be moved to a new location(s). While it's an opportunity to improve some legacy code, there are no functional changes intended. 

In other words, given some code does a task/activity at the moment, when it's moved, it should still do the same task.

As I see it, the project will pretty much have to run as follows:

1) developers identify what needs to migrate
2) developers tell BA what needs to be done and what functions will could be affected 
3) BA writes up everything the developers already know, as requirements
4) developers follow requirements which they already know because they determined them
5) QAs test functions which could be affected

I have very little technical knowledge (what I have has been gained by asking questions, but I have no technical training or background). All of the migrating code is background automation of existing processes. So I can't really see that I can add any value as a Business Analyst in this task.

So what I want to understand is whether other companies would use a BA in this project? 

Thanks for your input

From personal experience this will very much depend on the proposal or the scoping document or any kind of indication for the project sponsor(s) whether this is a lift and shift or whether you want to look at any efficiency opportunities as part of the change etc.

Also quite often (actually almost always) although the delivery team will say there will be no change for users, there are often changes which were either not expected or were not deemed as "worthy of being noted" e.g. UI changes, process changes, etc. As a BA you'd want to talk to all affected parties, understand how they currently use the system and then understand how the new environment will impact their day-to-day. Even if it's a purely back-end change there can often be impacts to end users e.g. certain parts of the front end are no longer accessible, or there is a workaround of some sort that was never discussed etc. So to me, documenting the current state from user's perspective is critical. This way we can clearly understand the impacts of the new process/system.

In short, if this is an IT led project - it'll often be done with less regard for users than if it was a business led project.