Merger
-
As Scott said, just pick up everything and make them separate at company A. You can even get your ISP to drop another line to the building so you have two connections, one for each business.
Though you can instead, if your ISP supports it, split the one connection over the two firewalls with a switch. This would allow you to have everything remain completely separate.
Of course doing that will still require the merger stuff we've talked about before.
-
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
-
@Dashrender said:
As Scott said, just pick up everything and make them separate at company A. You can even get your ISP to drop another line to the building so you have two connections, one for each business.
No need for that, just an IP address.
-
@Dashrender said:
Though you can instead, if your ISP supports it, split the one connection over the two firewalls with a switch. This would allow you to have everything remain completely separate.
No need, just use a real router
Like a $95 Ubiquiti. -
@Dashrender said:
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
That's how I feel. Start this now, move fast. Might be done in two weeks with six weeks to sit back and relax.
-
@scottalanmiller said:
@Dashrender said:
Though you can instead, if your ISP supports it, split the one connection over the two firewalls with a switch. This would allow you to have everything remain completely separate.
No need, just use a real router
Like a $95 Ubiquiti.Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
Though, how would you solve one IP for two RDS servers on the same IP/port? You found a good solution (OK Jason did) for the email one IP (Company A's email server receives all email, then forwards company B's email to company B's Exchange server. Though not sure how that would work in totally separate networks.
-
@Dashrender said:
Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
What do you mean? They'd be just as separate. In what way would they be less separate?
-
@Dashrender said:
Though, how would you solve one IP for two RDS servers on the same IP/port?
RDS Gateway. but no need, any real router will do multiple IPs on one WAN link.
-
@scottalanmiller said:
@Dashrender said:
Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
What do you mean? They'd be just as separate. In what way would they be less separate?
aww.. you're assuming a second IP on the ERL.. gotcha.
-
@scottalanmiller said:
@Dashrender said:
Though, how would you solve one IP for two RDS servers on the same IP/port?
RDS Gateway. but no need, any real router will do multiple IPs on one WAN link.
yeah, you mentioned an additional IP, I was leaving that out.
-
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
-
@Jason said:
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
Frankly, I'm curious about this as well?
-
@Jason said:
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
He/They didn't say
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
What do you mean? They'd be just as separate. In what way would they be less separate?
aww.. you're assuming a second IP on the ERL.. gotcha.
Correct. And then two networks internally.
-
@scottalanmiller said:
@Jason said:
@scottalanmiller said:
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
What is that?
He/They didn't say
Seems like this is the first thing that should be addressed.
-
@Jason said:
Seems like this is the first thing that should be addressed.
That would be my approach, if this were my project I would push on them HARD to determine that this is absolutely the truth and not just something that they are saying to blow off the idea. It's possible, but should lead to some questions about how they got into this state and how to avoid it in the future. I get the tight time frame, but this is making it tighter and getting the full picture here would potentially solve a lot of other things. Not everything by any stretch, but a bit.
-
@scottalanmiller said:
@Jason said:
Seems like this is the first thing that should be addressed.
That would be my approach, if this were my project I would push on them HARD to determine that this is absolutely the truth and not just something that they are saying to blow off the idea. It's possible, but should lead to some questions about how they got into this state and how to avoid it in the future. I get the tight time frame, but this is making it tighter and getting the full picture here would potentially solve a lot of other things. Not everything by any stretch, but a bit.
the legacy application is not compatible doesn't work with o365. the software vendor of the Document management sends emails with a tag so they can track all correspondence and auto save on to the documents management under each client without manually saving each email. this is done at the exchange level.
-
@scottalanmiller said:
@Dashrender said:
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
That's how I feel. Start this now, move fast. Might be done in two weeks with six weeks to sit back and relax.
that would be fine if no one was going to work for the next two months or no changes where going to be made
the main data migration still need to be done over a week end and out of hrs. -
What stops them from working? Sure you have to do big things like network file shares, etc during off time, but setting up the new AD, copying the users in, creating print queues, etc... all that can be done now.
-
@StefUk said:
@scottalanmiller said:
@Dashrender said:
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
That's how I feel. Start this now, move fast. Might be done in two weeks with six weeks to sit back and relax.
that would be fine if no one was going to work for the next two months or no changes where going to be made
the main data migration still need to be done over a week end and out of hrs.But you have to do it, right? So the sooner, the faster, the better? If you don't do it now, how will you do it later? And how does the process stop people from working?
